Практикум для системных администраторов Linux

Linux-администратор Advanced

Онлайн-практикум от команды Fevlake*

*8 лет обслуживаем IT-инфраструктуры

Начать путь в Linux

90% практики

45+ заданий

Онлайн–практикум -
практикуйтесь, когда вам удобно

Посмотреть Advanced уровень

Linux

Иконка топ 3

В топ 3

самых востребованных навыков для
системных администраторов и
DevOps-инженеров

Иконка стоимости

90 000 р.

Средняя зарплата специалиста по
направлению администрирование
Linux

Иконка кол-ва вакансий

2014

вакансий на территории РФ

*данные взяты с сайта hh.ru
Rebrain лого

Ваш путь в программе Linux by REBRAIN

Презентация практикума 10 минут

Записаться на практикум
1

Стажировка

Вы попадаете на виртуальную стажировку по направлению системное администрирование Linux.

2

Практикуйтесь, когда удобно

Проходите практикум в удобное для вас время. Срок практикума неограничен.

3

45+ заданий

Поэтапно проходите более 45 заданий. К каждому заданию прилагаются необходимые материалы для его выполнения.

4

Отвечаем быстро

Есть вопрос по заданию? Спрашиваете у авторов практикума и экспертов в закрытом чате Telegram.

5

Проверка за 24 часа

SLA 24 часа на каждое сданное задание.

6

Мастер–классы

Закрытые мастер-классы наших экспертов.

7

Выпускной проект

Полный кейс реального проекта.

8

Резюме

Готовим ваше резюме и передаем HR.

9

Finish

Помогаем подобрать интересный проект.

Практикум Linux Advanced by REBRAIN

  • 90% практики
  • 45+ рабочих задач
  • Не просто теоретические курсы администрирования Linux, а реальные кейсы агентства Fevlake
  • Множество практических кейсов, которые решают участники программ
  • Проверки заданий действующими инженерами​ максимум за 24 часа
  • Авторы - действующие DevOps из команды Fevlake
  • Доступ к крупнейшему сообществу по IT-инфраструктуре в СНГ
  • Чат с составителями практикума и действующими DevOps
  • Задания, которые можно показывать в портфолио
  • Обучение в удобное время

Кому подойдет практикум:

Начинающие системные администраторы

Разработчики

Специалисты по тестированию

Системные администраторы Microsoft

Программа практикума

Базы данных
  1. MariaDB
  2. PostgreSQL
  3. Redis
Веб-nginx
  1. Basics
  2. Proxy, access
  3. Conditions, regex
Интернет
  1. Apache
  2. PHP-FPM
  3. Let's encrypt
Сеть
  1. HAproxy
  2. Keepalived
  3. OpenVPN
  4. Pritunl
  5. Tinc
  6. Wireguard
  7. Ocserv
  8. BIND
  9. Unbound
  10. PowerDNS
  11. DHCPD
  12. dnsmasq
  13. PXE
Инфраструктура
  1. GPG
  2. Package repository
  3. LXC
  4. Libvirt
  5. Docker
  6. FreeIPA
Резервное копирование
  1. rsync
  2. borg
Хранение
  1. FTP
  2. NFS
  3. Samba
  4. iSCSI
  5. Glusterfs
  6. Ceph
Почта
  1. Postfix
  2. Dovecot
Мониторинг
  1. Netdata
  2. Zabbix
  3. Prometheus
  4. Grafana
Логирование
  1. logrotate
  2. Syslog
  3. Rsyslogd
  4. EFK
  5. Graylog

Примеры заданий

Ранее мы уже разобрали, что HTTPS используется для шифрования трафика между клиентом (скажем, браузером) и сервером, но, как не сложно догадаться, данный протокол покрывает передачу данных только по протоколу HTTP. Для других протоколов существуют другие реализации шифрования, которые, часто, для создания безопасного соединения используют все тот же TLS. Однако существует и другой инструмент, который создавался для шифрования отправляемых сообщений - PGP (Pretty Good Privacy) и его открытая реализация - GPG (GnuPG - GNU Privacy Guard), о котором мы и поговорим в этом задании

Начнем, как обычно, с короткой исторической справки. Для этого обратимся на секунду к странице на Wikipedia о PGP:

PGP - компьютерная программа, также библиотека функций, позволяющая выполнять операции шифрования и цифровой подписи сообщений, файлов и другой информации, представленной в электронном виде, в том числе прозрачное шифрование данных на запоминающих устройствах, например, на жёстком диске.

Из этого можно сделать вывод, что при помощи PGP можно производить следующие операции:

При этом данные могут быть представлены как файлами (как текстовыми, так и бинарными), так и текстом (скажем, текстом электронного письма)

Данная программа изначальна была создана с целью отправки зашифрованных сообщений через BBS (Bulletin Board System — электронная доска объявлений) и для хранения данных в шифрованном виде их разработчиком - Филиппом Циммерманом - в ходе его движения против ядерной энергии в начале 90-х годов. В последствии же данная программа была распространена в открытом виде для использования кем угодно. Однако из-за разночтений ранних реализаций данного инструмента, в 1997 году компания PGP Inс., ответственная на тот момент за разработку этого инструмента, предложила стандарт OpenPGP, который детально описывал, как должны работать реализации для взаимной совместимости. Данный стандарт был принят IETF как RFC4880. На базе этого протокола был создан инструмент GNU Privacy Guard (GnuPG/GPG), который и поставляется во всех современных дистрибутивах. На данный момент актуальной мажорной версией утилиты является вторая версия, из-за чего иногда можно встретить указание GPG2, но в реальности команда для работы с GPG осталась одна - gpg

Протокол PGP подразумевает использование ассимметричных, симметричных алгоритмов шифрования, а также использование алгоритмов сжатия. Протоколы шифрования используются для тех же целей, что и в TLS - шифрование данных и создание цифровых подписей. И, ровно как в случае с TLS, при установке сессии с другим клиентом, ассиметричная пара ключей используется для шифрования сессионного ключа, который используется для общения по симметричному алгоритму шифрования. Однако PGP позволяет кроме того шифровать и произвольные данные, такие как файлы, при помощи ассиметричных ключей, что позволяет организовывать защищенный обмен и хранение данных в зашифрованном виде. К примеру, данная возможность используется в утилите для снятия бекапов с баз WAL-G с целью шифрования бекапов при помощи публичного ключа перед их сохранением в шифрованном виде. При такой схеме для разворачивания бекапа требуется наличие приватного ключа у пользователя, от имени которого запускается данная утилита

GPG подразумевает 2 схемы работы - через сертификаты (по аналогии с TLS), а также через так называемую сеть доверия, которая подразумевала, что для корректной работы с другим человеком вам нужно получить от него публичный ключ и добавить в свой keychain и только тогда - расшифровать сообщения от данного пользователя. Хотя данный подход к организации инфраструктуры управления открытыми ключами и позволяет обеспечить децентрализованную защищенную систему для общения между клиентами, широкого распространения она не получила

Теперь разберемся с самой утилитой gpg и что мы можем с ней сделать

Генерация ключей

Как мы описали выше, GPG подразумевает использование ассиметричных ключей для своей работы. Каждый ключ в GPG привязан к определенному человеку. Чаще всего - к его адресу электронной почты, как универсальному идентификатору. В gpg для генерации пары ключей существует несколько разных команд для генерации ключей. Начнем с более общей

--full-generate-key / --full-gen-key - позволяет в интерактивном режиме задать все параметры создаваемого ключа:

  1. Какого типа ключ требуется создать - позволяет определить, для каких целей будет походить ключ (для всех целей или только для подписей)
  2. Какой длины ключ должен быть создан - данный параметр влияет на криптоустойчивость ключа, а также сколько энтропии может понадобиться на генерации ключа (на ноутбуках это не так ощущается, но на серверах длинные ключи могут генерироваться очень долго)
  3. Сколько времени будет валиден ключ - актуально, к примеру, для временного ключа, который используется для подписи. На этом этапе можно сделать ключ, который не истечет
  4. Имя пользователя
  5. E-Mail пользователя
  6. Комментарий к ключу - необязательное поле

После этого производится ввод парольной фразы (passphrase) - пароля, который будет запрашиваться при использовании ключа. Можно оставить данное поле пустым, тогда пароль не будет установлен

Частным случаем данной команды является --generate-key / --gen-key - она генерирует пару ключей с длиной ключей в 2048 байт, который истечет через год и может использоваться для всех целей. В ходе создания ключа будет запрошено только имя, e-mail и passphrase

Все ключи хранятся в домашнем каталоге ~/.gnupg, однако, как правило, обращение к ключам производится через утилиту, а не напрямую

Вывод ключей публичных и приватных

Для вывода публичных ключей в вашем хранилище (или keyring) используется флаг --list-keys или, в сокращении, -k. Пример вывода:

$ gpg -k

/home/dolan/.gnupg/pubring.kbx

pub rsa4096 2017-02-22 [SCEA] 9DC858229FC7DD38854AE2D88D81803C0EBFCD88

uid [ unknown] Docker Release (CE deb) <[email protected]>

sub rsa4096 2017-02-22 [S]

pub rsa2048 2020-07-01 [SC] [expires: 2022-07-01] 54BB9ED7ED3584A911143D0416901E2B8AB7C492

uid [ultimate] [email protected] <[email protected]>

sub rsa2048 2020-07-01 [E] [expires: 2022-07-01]

pub rsa2048 2020-07-01 [SC] 0A2314DCBF13E2068D465521ABFA559546CFCD04

uid [ultimate] qwerty <[email protected]>

sub rsa2048 2020-07-01 [E]

Из этого вывода можно увидеть 3 ключа - первый был импортирован вручную для apt репозитория, второй был создан с флагом --gen-key, а третий - с --full-gen-key

Для вывода имеющихся приватных ключей используется ключ --list-secret-keys или его сокращенная форма - -K:

$ gpg --list-secret-keys

/home/dolan/.gnupg/pubring.kbx

sec rsa2048 2020-07-01 [SC] [expires: 2022-07-01] 54BB9ED7ED3584A911143D0416901E2B8AB7C492

uid [ultimate] [email protected] <[email protected]>

ssb rsa2048 2020-07-01 [E] [expires: 2022-07-01]

sec rsa2048 2020-07-01 [SC] 0A2314DCBF13E2068D465521ABFA559546CFCD04

uid [ultimate] qwerty <[email protected]>

ssb rsa2048 2020-07-01 [E]

Как видете, вывод отличается от вывода с публичными ключами тем, что в нем отсутствует приватный ключ, так как мы импортировали только публичную часть ключа, которая используется для подтверждения подписей

Экспорт ключей

Для того, чтобы передать другому человеку свой публичный ключ, его сперва нужно экспортировать из своего хранилища. Для этого используется флаг --export с передачей идентификатора ключа, e-mail или даже имени пользователя ключа, к которому привязан ключ. Так, к примеру, для экспорта последнего ключа можно использовать следующие команды:

  1. gpg --export 0A2314DCBF13E2068D465521ABFA559546CFCD04
  2. gpg --export qwerty
  3. gpg --export [email protected]

Одно но - данный файл экпортирует в бинарном виде, который можно сохранить через перенаправление потока, но не скопировать текстом. Для того, чтобы можно было это передать, в читаемом и копируемом виде, можно воспользоваться флагом --armor, который переводит бинарные данные в символьное представление, которое уже можно копировать:

$ gpg --armor --export qwerty

-----BEGIN PGP PUBLIC KEY BLOCK-----

mQENBF78gQ0BCADIi+tUIsHOgdQsDoYVXL7WIs0LgN4s88Wai8U/tg0px4Gs4UJeDcHicFfCN46XUtUE1LV9vqpQhK/r33V4VUitvxi0XWlyY8Y4z/Ue+qBB9x6LzW7s0xNNZ/1Y1g8gFoAUik3lRe2Hu23RDiZtHNNq04xUz+w12a86R2zElRo+s+PjxC8/jgq3YcIQUyk1lBHTIDV+pUeD8OA2jzSkLfBYTJiyzQw1WXZAPu2nx5hOO7irl7Nb3QzKDKaOASGnGn7tLwDs880nPXSkqEsrpMWnQ+V2ZG0nloaL32uKndKxIEIGSEdxNvHASyy3XYpbkFX1EeyEPLxNZ5WvIJWiCKY1ABEBAAG0F3F3ZXJ0eSA8cXdlcnR5QG5hbWUuY28+iQFOBBMBCAA4FiEECiMU3L8T4gaNRlUhq/pVlUbPzQQFAl78gQ0CGwMFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQq/pVlUbPzQT/0wf+OAF0VZ4L/rNDlwkzT3vcHaL0r35dkz4xB8xR2dJ4/S83B5vG7I+6HCCWUXTK78rFDInVQr19f2e404iqE5fSN4+8ntQbdm+T1nWWAJvA/z5JJjrF4eJpqZJHDGfDIRoJtuyelsxZ4j8iQuwBDIIvtgAkI6MWAcOW5xrDq/wtjmPTFC1KZh1E/rA+nDQUlvFW0Wm5mmRBz3WYfL3QX26+cwH8JlqMB2Kg7wowepB2/ssG9SpXoCEg4v2T1WbRF9N3giA3K9O9cyxU4ggXY3OrDy8B+MXqqgldXs4Ugnsd8tDEFwN6AKRHEFQR313Grdw6bRivHGJJ7TuvXm30d2OyLLkBDQRe/IENAQgAvdYytjHxvyC13PXcUK+WJxF0+Wiu0+UbX+wVOHuYYBjHtfAmjnXOAxCLLsuF8ev6vTWaMCrKdE6nC3gVwSJQL/2ga085IolN3vLgldfQVSHDUEXEsbj8pAlnZd6NkZs0GJjC6dECT6/nS4hLip/d1/KNsJ/XYnNDCTAqdyH4P6Dpct6iNiMPeKT28IzckyDl9CZEDWcpVotuu8EmMvcxZJMmX+2kdMmI6BFmCO3PnAdRzsLk4wymx97zjfu8C/Xt6lIwXhjDaY8Bg0XYPCFcJNmLWyzE4ICuJdW0S61VaNfLj8QrJaSvDv5OIICOpHye+LnmLdBxBeyjx00tBIvnXQARAQABiQE2BBgBCAAgFiEECiMU3L8T4gaNRlUhq/pVlUbPzQQFAl78gQ0CGwwACgkQq/pVlUbPzQTMPggAsY85ztfHapc66qrMmF1iCI81eQJsj6J4ylQWrGMKhg5UYq+yDXdHUsSEQ4AH0kbQPWIu5Op8ZOfPRWOZCrQhcu1UNME+dQ54Me5HXuJmsm9NbXhgPrcM8mnFNyPPXS3MWwfCHk7FGSWCYvQAcJUSeLdZfbVGbLhaGfitpc/P9GrzfNcgThOl66AtixycmXnrIxSsHxV3uh8PkGYQzKWcwYO9Xj82DeZtYGjwjQhn2bn5jjHoRPOQu356+LF1tbdMoPsjI8msiD3gjKKCbCLGDr8+UtT/pRN0RN9BDNS/1w7IuR1skeJ6y6tstjkQ
TcoJc0IrlS0i7ONNEkeXvS4Zcw==
=azb7

-----END PGP PUBLIC KEY BLOCK-----

В данном выводе важны заголовок, последняя строка и вторая пустая строка - их наличие означает, что файл валидно экспортирован (хотя пустая строка может показаться странной)

Если же требуется экспортировать приватный ключ, стоит использовать вместо ключа --export ключ --export-secret-keys. Формат вывода будет отличаться, размер ключа - тоже, но в в остальном все работает абсолютно также

Импорт ключей

В случае же, если вам передали ключ, то для работы с ним вам требуется его импортировать. Для этого используется флаг --import, которому требуется передать имя файла, либо его можно использовать через | для импорта из потока ввода. Вывод данной команды сообщит, какие сущности были импортированы:

$ gpg --import /tmp/qwerty

gpg: key ABFA559546CFCD04: "qwerty <[email protected]>" not changed

gpg: key ABFA559546CFCD04: secret key imported

gpg: Total number processed: 1

gpg: unchanged: 1

gpg: secret keys read: 1

gpg: secret keys imported: 1

В случае же, если данный ключ у вас уже добавлен, утилита вам об этом сообщит:

$ gpg --import /tmp/qw

gpg: key ABFA559546CFCD04: "qwerty <[email protected]>" not changed

gpg: key ABFA559546CFCD04: secret key imported

gpg: Total number processed: 1

gpg: unchanged: 1

gpg: secret keys read: 1

gpg: secret keys unchanged: 1
Удаление ключей

Если же вы хотите удалить ваш ключ из хранилища, можно воспользоваться флагами --delete-keys, --delete-secret-keys и --delete-secret-and-public-keys для удаления только приватного, только публичного или обоих ключей соответственно. При удалении gpg несколько раз уточнит у вас, уверенны ли вы в своем действии, так как то, что удалено, возвращению не подлежит

Изменение ключей

Имея приватный и публичные ключи, вы можете изменять некоторые параметры ключа, в интерактивном режиме при помощи ключа --edit-key. К примеру - для удалить дату истечения действия ключа или установить/удалить passphrase. Пример входа в редактор:

$ gpg --edit-key 54BB9ED7ED3584A911143D0416901E2B8AB7C492
gpg (GnuPG) 2.2.20; Copyright (C) 2020 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Secret key is available.

sec rsa2048/16901E2B8AB7C492
created: 2020-07-01 expires: never usage: SC
trust: ultimate validity: ultimate
ssb rsa2048/536E30C75D07B654
created: 2020-07-01 expires: 2022-07-01 usage: E
[ultimate] (1). [email protected] <[email protected]>

gpg>

Обратите внимание, что в выводе 2 ключа - 16901E2B8AB7C492 и 536E30C75D07B654. Переключение между ними производится через директиву key и указанием его идентификатора:

gpg> key 536E30C75D07B654

sec rsa2048/16901E2B8AB7C492
created: 2020-07-01 expires: never usage: SC
trust: ultimate validity: ultimate
ssb* rsa2048/536E30C75D07B654
created: 2020-07-01 expires: 2022-07-01 usage: E
[ultimate] (1). [email protected] <[email protected]>

gpg>

Это требуется для работы с каждым подключем (что особенно важно, к кримеру, при удалении даты истечения ключа)

Шифрование сообщений

Для шифрования данных можно использовать 2 подхода - публичный ключ принимающего или фиксированная passphrase. Первый вариант использует ассимметричный алгоритм шифрования и использует публичный ключ (тогда для расшифровки потребуется приватный ключ), а для второго - симметричный алгоритм, где ключем выступает введенная passphrase

Если данным командам передавать в конце имя файла, который требуется зашифровать, то оно и будет зашифрованно. Иначе же можно зашифровать данные, передаваемые через stdin, к примеру, через |

Расшифровка сообщений

Для расшифровки сообщений требуется либо владение приватным ключем, которым был зашифрован файл, либо знание passphrase. В любом случае, расшифровака сообщения производится командой gpg --decrypt с передачей имени зашифрованного файла, либо передачи данных через stdin

  1. Сгенерируйте ключ при помощи флага --gen-key (команды и вывод сохраните)
  2. Выведете список публичных и приватных ключей (команды и вывод сохраните)
  3. У созданного ключа удалите дату истечения (команды и вывод сохраните)
  4. Выведете список публичных и приватных ключей (команды и вывод сохраните)
  5. Экспортируйте публичный ключ в файл в ASCII формате и выведете его (команды и вывод сохраните)
  6. Экспортируйте приватный в бинарном виде в файл (команду и вывод сохраните)
  7. Зашифруйте строку RebrainMe Linux ASYM при помощи сгенерированного ключа в ASCII формате и выведете этот файл (команды и вывод сохраните)
  8. Зашифруйте файл с приватным ключем при помощи passphrase secret в ASCII формате и выведете этот файл (команды и вывод сохраните)
  9. Удалите из вашего хранилища публичный и приватный ключ (команды и вывод сохраните)
  10. Выведете список публичных и приватных ключей (команды и вывод сохраните)
  11. Расшифруйте приватный ключ и импортируйте одной командой (команды и вывод сохраните)
  12. Выведете список публичных и приватных ключей (команды и вывод сохраните)
  13. Расшифруйте файл с зашифрованной строкой (команды и вывод сохраните)
  14. Отправьте на проверку все сохраненные выводы

Интернет - это глобальная сеть, через которую можно получить огромное количество данных, начиная от видеопотока с вашими друзьям и родственниками, заканчивая корпоративными данными с вашего места работы. Наиболее распространенным окном в Интернет является браузер, через который отрисовывывается вся эта информация. Однако если то, как пользоваться браузером, сейчас понятно почти каждому, то какое приложение отдает нам контент из интернета - более широкая тема. В рамках этого и последующих блоков мы будем разбирать инфраструктурные компоненты один за одним, чтобы у вас сформировалось как понимание, так и опыт работы с ними. Начнем мы с web-серверов - тех серверов, которые и обрабатывают бОльшую часть запросов на первой линии, либо выполняя работу сами (к примеру, отдача картинок), либо передавая запросы другим компонентам (например, самописные приложения или прочие внутренние сервисы).

Начнем мы этот блок с одного из самых распространенных веб-серверов - nginx. Данный инструмент, разработанный Сысоевым Игорем Владимировичем, на самом деле, является намного более, чем просто web-сервером, который способен отдавать только данный ему контент (хотя с этим он справляется прекрасно), но также способен перенаправлять запросы на другие сервисы (которые, к примеру, могут находиться в защищенном сегменте сети вашей компании), включая протоколы HTTP, SMTP, IMAP, POP3. При особом желании nginx можно использовать и как прокси для любых других UDP и TCP протоколов. За счет этого частыми случаями использования nginx являются:

пограничная точка входа из интернета во внутреннюю сеть; терминирование SSL трафика; проксирование запросов по другим приложениям; изменение трафика (к примеру, добавление/удаление HTTP заголовков); балансировщик нагрузки.

Как правило, конфигурационные файлы nginx расположены в директории /etc/nginx/, где главным файлом является /etc/nginx/nginx.conf. Приведем пример базового конфигурационного файла nginx:
user www-data;
worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;

events {
worker_connections 768;
# multi_accept on;
}

http {
##
# Basic Settings
##

sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 65;
types_hash_max_size 2048;
# server_tokens off;

# server_names_hash_bucket_size 64;
# server_name_in_redirect off;

include /etc/nginx/mime.types;
default_type application/octet-stream;

##
# SSL Settings
##

ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Dropping SSLv3, ref: POODLE
ssl_prefer_server_ciphers on;

##
# Logging Settings
##

access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;

##
# Gzip Settings
##

gzip on;

# gzip_vary on;
# gzip_proxied any;
# gzip_comp_level 6;
# gzip_buffers 16 8k;
# gzip_http_version 1.1;
# gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

##
# Virtual Host Configs
##

include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
}

mail {
See sample authentication script at:
# http://wiki.nginx.org/ImapAuthenticateWithApachePhpScript

# auth_http localhost/auth.php;
# pop3_capabilities "TOP" "USER";
# imap_capabilities "IMAP4rev1" "UIDPLUS";

server {
listen localhost:110;
protocol pop3;
proxy on;
}

server {
listen localhost:143;
protocol imap;
proxy on;
}
}

Каждая строка в данном файле является директивой, определяющей логику работы. Кроме простых директив, которые отделяются друг от друга символом ;, существуют и блоки директив, которые могут располагаться лишь в конкретном отношении друг к другу. Некоторые блоки могут повторяться, некоторые же могут встречаться лишь один раз. В первом приближении уровни конфигурационного файла выглядят следующим образом:

main
-- events
-- http
---- server
------ location
---- server
------ location
-- mail
---- server
---- server

Где уровень main - это основной, включающий такие директивы, как user, pid и другие. nginx является модульным приложением. Это значит, что каждая из директив в конфиге связана с определенным модулем. Так, к примеру, модуль ngx_core_module отвечает за основную логику web-сервера - то есть определяет как раз те директивы, без которых сервер бы просто не запустился (к примеру, упомянутый user). Модули существуют двух видов - статические и динамические. Статические - это те модули, которые входят в состав nginx в результате сборки nginx из исходных кодов с добавлением кода необходимого модуля. Динамические же - это модули, которые можно подключать к nginx без сборки самого nginx, хотя сам модуль приходится собирать во внешнюю библиотеку (если, конечно, его нет в виде уже собранного пакета). Однако, увы, nginx не позволяет подключить динамический модуль, если в ходе сборки самого nginx мы не указали в параметрах сборки поддержку конкретного динамического модуля. Иначе говоря - если вам требуется конкретный модуль, то вам в любом случае необходимо собирать nginx из исходных файлов. А вот как - уже на ваше усмотрение и исходя из возможностей работы модуля (не все модули, к примеру, умеют работать как динамические).

Для получения информации о вашей версии nginx, сборке и модулях используется флаг -V при вызове nginx:

# nginx -V
nginx version: nginx/1.14.0 (Ubuntu)
built with OpenSSL 1.1.1 11 Sep 2018
TLS SNI support enabled
configure arguments: --with-cc-opt='-g -O2
-fdebug-prefix-map=/build/nginx-GkiujU/nginx-1.14.0=. -fstack-protector-strong -Wformat
-Werror=format-security -fPIC -Wdate-time -D_FORTIFY_SOURCE=2'
--with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now -fPIC'
--prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf
--http-log-path=/var/log/nginx/access.log --error-log-path=/var/log/nginx/error.log
--lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid
--modules-path=/usr/lib/nginx/modules --http-client-body-temp-path=/var/lib/nginx/body
--http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-proxy-temp-path=/var/lib/nginx/proxy
--http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi
--with-debug --with-pcre-jit --with-http_ssl_module --with-http_stub_status_module
--with-http_realip_module --with-http_auth_request_module --with-http_v2_module
--with-http_dav_module --with-http_slice_module --with-threads --with-http_addition_module --with-http_geoip_module=dynamic
--with-http_gunzip_module --with-http_gzip_static_module --with-http_image_filter_module=dynamic
--with-http_sub_module --with-http_xslt_module=dynamic --with-stream=dynamic
--with-stream_ssl_module --with-mail=dynamic --with-mail_ssl_module

Из данного вывода можно понять, что на сервере - nginx версии 1.14.0, который использует по умолчанию конфигурационный файл из /etc/nginx/nginx.conf и, к примеру, собран с модулем для работы с gzip, а также использует подключенный к нему модуль для работы с протоколом SMTP (mail).

Подключение динамического модуля производится через директиву load_module в секции main. Соответственно, если мы не используем данный модуль, мы можем просто не загружать его, убрав соответствующиую директиву.

Перед тем, как разбирать основные директивы, уточним, что в конфигурационном файле существует несколько основных правил:

Все директивы должны заканчиваться символом ;.
Блоки директив (тот же http) НЕ заканчиваются ;.
Для комментирования строки используется #.
У каждой директивы есть свой разрешенный контекст (этот пункт мы разъясним далее, после примера конфигурационного файла).

Далее мы будем разбирать основные директивы, с которыми приходится работать чаще всего:

include
Директива include позволяет подключать другие файлы вместо директивы. Выглядит это так, что в ходе запуска сервиса nginx компилирует конфигурационный файл, вставляя вместо этой директивы содержимое тех файлов, которые подключаются, и применяет директивы одну за одной (поэтому последовательность директив важна). Важно то, что в ходе такого подключения с использованием * подключение файлов производится в алфавитном порядке, поэтому, если вам нужно какой-то конфигурационный файл поставить первым для выполнения, его можно назвать с использованием числа первым символом имени файла (например: 10-base.conf, 20-addition.conf)

В нашем примере эта директива используется в 2 секциях - main (3 строка) для подключения динамических модулей и http. Так, к примеру, подключаемый файл может выглядеть следующим образом:

server {
listen 80 default_server;
listen [::]:80 default_server;

# SSL configuration
#
# listen 443 ssl default_server;
# listen [::]:443 ssl default_server;
#
# Note: You should disable gzip for SSL traffic.
# See: https://bugs.debian.org/773332
#
# Read up on ssl_ciphers to ensure a secure configuration.
# See: https://bugs.debian.org/765782
#
# Self signed certs generated by the ssl-cert package
# Don't use them in a production server!
#
# include snippets/snakeoil.conf;

root /var/www/html;

# Add index.php to the list if you are using PHP
index index.html index.htm index.nginx-debian.html;

server_name _;

location / {
# First attempt to serve request as file, then
# as directory, then fall back to displaying a 404.
try_files $uri $uri/ =404;
}

# pass PHP scripts to FastCGI server
#
#location ~ \.php$ {
# include snippets/fastcgi-php.conf;
#
# # With php-fpm (or other unix sockets):
# fastcgi_pass unix:/var/run/php/php7.0-fpm.sock;
# # With php-cgi (or other tcp sockets):
# fastcgi_pass 127.0.0.1:9000;
#}

# deny access to .htaccess files, if Apache's document root
# concurs with nginx's one
#
#location ~ /\.ht {
# deny all; #}
}

Так, include в http добавит новый блок server, который определит информацию о новом виртуальном хосте, то есть о доменном имени.

Вернемся к последнему пункту основных правил, которые мы привели выше (у каждой директивы есть свой разрешенный контекст). Он подразумевает, что каждая директива может находиться лишь в конкретных подуровнях конфигурационного файла. Связано это с приязкой к фунциональности и гибкости конкретного модуля. Так, например, поскольку пользователь, от имени которого запускается nginx, может быть установлен только один раз, то его можно установить лишь в контексте main, в то время как директива error_log может быть установлена практически в любом контексте. Для того чтобы узнать, в каком контексте можно использовать конкретную директиву, нужно смотреть документацию модуля, отвечающего за эту директиву. Для примера приведем выдержку из документации модуля ngx_core_module для директивы user:

Syntax: user user [group];
Default: user nobody nobody;
Context: main
и директивы error_log:
Syntax: error_log file [level];
Default: error_log logs/error.log error;
Context: main, http, mail, stream, server, location

Но, как правило, чтобы узнать, из какого модуля конкретная директива, достаточно в поисковике просто ввести запрос nginx $DIRECTIVE и, с высокой долей вероятности, вы найдете информацию о нужной директиве в одном из первых результатов поиска.

log_format
Директива log_format позволяет описать, что будет содержаться в журнале запросов - какие поля и в какой очередности.

По умолчанию, nginx использует следующий формат логов (названный combined): log_format combined '$remote_addr - $remote_user [$time_local] ' '"$request" $status $body_bytes_sent ' '"$http_referer" "$http_user_agent"';

По аналогии с bash, все, что начинается со спецсимвола $, - это переменные, большинство из которых доступно по умолчанию. Однако, как мы увидим далее, возможно задать новые переменные, которые также можно отдавать в логах, описав их новый формат.

access_log
Форматы логов используются в директиве access_log следующим образом - access_log ${LOG_PATH} ${LOG_FORMAT}. Пример использования - access_log /var/log/nginx/access.log combined.

Возможно в одной директиве использовать несколько access_log, чтобы писать в разные файлы с разными форматами. Это бывает полезно, когда нам нужны разные уровни детализации либо логи далее используются каким-то еще сервисом.

error_log
Кроме access log, существует еще один лог - error_log. Он используется для записи ошибок работы nginx. В отличие от директивы access_log, в error_log передается не формат логов, а минимальный уровень детализации. По умолчанию используется уровень error, но существуют и другие уровни, вплоть до debug. Пример использования - error_log /var/log/nginx/error.log debug.

server
Директива server определяет так называемый виртуальный хост, что позволяет на одном IP-адресе обрабатывать несколько доменов. С точки зрения внутренней логики, определение производится по HTTP заголовку Host, который выставляется, когда вы обращаетесь к конкретному серверу по DNS-имени. Каждый server может быть запущен на своем адресе и порту, либо обрабатывать конкретное (или несколько конкретных) DNS-имен. Кроме того, можно создать server, который привязан не к конкретному доменному имени, а только к порту. По умолчанию nginx устанавливается с конфигурационным файлом для такого обработчика. Далее рассмотрим директивы, которые отвечают за конфигурацию этих параметров сервера.

server_name
При помощи директивы server_name можно как раз указать, какие DNS-имена будет обрабатывать конкретный server. Так, к примеру, если мы хотим определить, чтобы сервер обрабатывал только домен example.com, то директива должна выглядеть просто как server_name example.com;

Если же требуется обрабатывать несколько доменных имен, то они указываются друг за другом и разделяются пробелами, к примеру, server_name example.com www.example.com;

Кроме этого, директива позволяет устанавливать wildcard правила, которые, к примеру, позволяют обрабатывать все субдомены - server_name example.com *.example.com;.

Отдельным случаем является использование пустого server_name ("") - он определяет, что запросы без Host (к примеру, по IP-адресу) будут обрабатываться этим server. В случае, если необходимо потестировать работу конкретного server по server_name с локали, то есть возможность добавить соответствующую запись в /etc/hosts или при запросе через тот же curl установить заголовок Host при запросе.

listen
Данная директива позволяет определить, где слушает конкретный сервер - какой порт, какой IP-адрес или вообще Unix сокет. Кроме этого, он позволяет установить большое количество опций по работе сервера, например, используется ли SSL, по какому протоколу производится общение с сервером (к примеру, HTTP2 или HTTP1) и так далее.

Самый распространенный случай использования - это определение порта, на котором слушает сервер и частые опции - http2 и ssl. Такой кейс в виде директивы выглядит как listen 443 http2 ssl. Также популярен и, пусть и простой, но очень важный формат, который позволяет повесить сервер на конкретный порт без SSL - listen 8080. Эти два сценария использования данной директивы наиболее распространены и встречаются наиболее часто.

Кроме описанных выше, есть еще одна очень важная опция - default_server, которая определяет, что конкретно этот сервер будет использоваться по умолчанию для пары IP-адрес - порт. Представим, что у нас есть 3 server:

server_name ""; listen 80 default_server;
server_name example.com; listen 80;
server_name ""; listen 127.0.0.1:80 default_server;

Каждый из них имеет право жить и будет обрабатывать разные запросы.

location
Мы наконец подобрались к одной из основных директив для блока server, которая сама является блоком, - location. Она используется для определения логики по определенным путям и на нее завязана работа некоторых других директив. Продублируем пример директивы из блока выше с примером server:

location / {
try_files $uri $uri/ =404; }

Как видите, внутри нее могут располагаться другие директивы, актуальные именно для этого пути. Далее начнем разбираться с подобными директивами.

root/alias
Теперь разберем то, как отдавать статический контент с вашего сервера. К счастью, nginx с этим справляется прекрасно и часто используется именно для отдачи статики, снимая эту нагрузку с сервисов, которые занимаются обработкой динамических запросов (но об это позднее).

Для этого существует 2 директивы - root и alias. Они схожи по функциональности, но работают немного по-разному, поэтому необходимо разбираться, как они действуют. Начнем с root - данная директива определяет, какой путь выступает корнем пути. Относительно него определяется, к какому файлу обращаться при запросе.

Представим, что у нас есть директория /var/www/static, в которой у нас есть изображения. В этом случае мы можем установить директиву root /var/www/static, и тогда при обращении к пути /image.png мы, по факту, обратимся к файлу /var/www/static/image.png.

При этом не важно, в каком location мы установим эту директиву, файл будет включать в поиск полный путь.

В случае же директивы alias мы создаем некую символическую ссылку, и обращение будет производиться к файлу без добавления location к пути. Тут возникает важная разница между root и alias: первый - абсолютный, второй - относительный. Из-за этого появляется особенность работы со слешем в конце директивы. Приведем пример server и разберем запросы на примере:

server {
listen 80;
server_name example.com;

location /a {
root /www; }
location /b {
root /www/; }
location /c {
alias /www; }
location /d {
alias /www/; }
}

4 location здесь для того, чтобы показать влияние слеша в конце пути. Реальное же обращение по файлам будет следующее:

http://example.com/a/my/file -> /www/a/my/file
http://example.com/b/my/file -> /www/b/my/file
http://example.com/c/my/file -> /wwwmy/file # вряд ли мы этого хотели
http://example.com/d/my/file -> /www/my/file

В целом, документация рекомендует не использовать директиву root внутри location, а выносить ее в контекст server, но бывает, что без этого не обойтись.

На этом закончим наше первое знакомство с nginx, но продолжим еще в следущем задании, в котором разберем, как мы можем ограничить доступ к нашему серверу и использовать nginx в роли reverse proxy.

  1. Это задание выполняется на виртуальной машине, которую Вы создаете самостоятельно на инфраструктуре Ребрейн. Необходимая информация и инструкции размещены на вкладке "Инфраструктура" (просьба строго соблюдать). Для создания/удаления виртуальной машины Вы можете использовать любой знакомый Вам инструмент (например, Terraform) или утилиту hcloud.
  2. Пример использования hcloud:
    hcloud ssh-key create --name <your_ssh_key_name> --label 'module=linux’ --label 'email=ii_at_rebrainme_com' --public-key-from-file string <path_to_pub_key>
    hcloud server create --name <server_name> --type cpx11 --ssh-key <your_ssh_key_name> --label 'module=docker' --label 'email=ii_at_rebrainme_com' --image ubuntu-18.04
  3. Установите пакет nginx-full.
    Напишите конфигурационный файл nginx, который реализует следующую функциональность:
  4. Отключен модуль mail.
    В отдельном конфигурационном файле должен быть описан server, который слушает на 80 порту и использует домен, полученный при помощи сервиса http://xip.io/. Используется формат логов с именем logz, который содержит только информацию о том, откуда был произведен запрос, в какое время, какой был произведен запрос и какой HTTP код был возвращен при запросе. Логи должны писаться в файл /var/log/nginx/xip.access.log. В роли root используется /var/www/html/. В роли index - /var/www/html/index.nginx-debian.html, которая должна возвращаться при обращении к /. Путь /rbm_images/* должен отдавать файлы из /var/www/rebrain/images/, где должен быть расположен файл http://rebrainme.com/files/logo_rebrain_black.png под именем logo.png.
  5. В ответе пришлите:
    конфигурационный файл для основного сервера и путь до него; список файлов в /etc/nginx/modules-enabled/.

В предыдущих заданиях мы рассматривали решения для работы с логами, которые подразумевают хранение логов в неструктурированном виде. Все, что отличает один лог от другого, — это severity, facility, хост, с которого отправляли, и приложение (еще может быть тег, но все равно, не особо гибко). В рамках этого задания мы рассмотрим другой подход к хранению логов — в виде структурированных объектов.

Логи, как мы уже обсуждали, позволяют нам узнать от приложений, как и что пошло не так. Часто они летят просто в файлы, из которых нам приходится разбирать данные утилитами типа grep, awk, sed или вообще самописными утилитами/скриптами. Однако иногда хочется не искать их самому, а просто ввести запрос как в Google и получить все логи, содержащие ту или иную строку. ElasticSearch (далее ES), который мы будем рассматривать в этих задачах, как раз и был создан для решения таких задач (изначально, на самом деле, других, но под наши задачи важна именно эта цель).

Разберемся же, что такое ElasticSearch — это поисковая система, написанная на Java компанией Elastic. Общение с ней производится по JSON REST API (то есть, в браузере без дополнительных плагинов общаться с ES не получится). Он используется для поиска данных в документах, что позволяет использовать его как нереляционную базу данных, которая умеет хорошо искать данные по заданному тексту среди своих документов. Документы в ES организованы по индексам, что позволяет разделять приходящие документы по логическому имени (скажем, common_logs и super_important_logs).

Особенностью ES является то, что он хорошо справляется с большим количеством документов, а также умеет легко горизонтально расширяться за счет добавления дополнительных нод практически без боли.

В разрезе темы с логами важно сказать, что искать документы можно не только в одном индексе, а в нескольких одновременно. Важность этого мы поймем чуть далее.

Приведем пример запроса к ES, для того чтобы иметь представление, как отправляются данные и что мы получим в итоге:

# curl -XPUT "localhost:9200/blog/post/1?pretty" -d'
{
"title": "Веселые котята",
"content": "<p>Смешная история про котят<p>",
"tags": [
"котята",
"смешная история"
],
"cuteness": 7,
"published_at": "2014-09-12T20:44:42+00:00"
}'

{
"_index" : "blog",
"_type" : "post",
"_id" : "1",
"_version" : 1,
"_shards" : {
"total" : 2,
"successful" : 1,
"failed" : 0
},
"created" : false
}

Рассмотрим запрос детально:

Пока просто держим это в голове, поскольку к этому документу мы еще вернемся.

Вернемся к проблеме (с точке зрения использования простым человеком), что запросы к ES можно делать только по JSON REST API. Напрашивается же какой-то инструмент, который позволит удобно запрашивать, просматривать и фильтровать логи. Специально для этих целей разработчики ES создали инструмент Kibana.

Картинка

Благодаря нему, мы и получаем ту самую поисковую строку, которая позволит найти все необходимые данные и вывести их для удобного просмотра.

В Kibana можно производить простые запросы прямыми запросами типа Error, что вернет все документы, содержащие эти слова. Но вся сила этой поисковой строки состоит в умении запрашивать с использованием сложных выражений и правил форматирования, подобных тем, что мы использовали при написании скриптов в if/else в bash. Это бывает необходимо, когда мы пользуемся полями документа (мы как раз их отправляли выше). Приведем примеры, связанные с нашим документом:

Кроме формата запросов по умолчанию, который пришел в Kibana и ES из Lucene (билиотека для поиска от фонда Apache), у Kibana существует еще и свой язык запросов, называемый Kibana Query Language (или KQL). Он позволяет писать запросы, которые ближе к SQL и другим запросам, как в языках программирования.

Kibana оперирует понятием Index Patterns — объединение индексов по имени, что может быть очень полезно, если у нас есть индексы, разделенные по дате (к примеру, logs-20.10.01 и logs-20.10.02, но к этому мы еще вернемся). Это позволяет производить запросы сразу на группу индексов, расширяя тем самым ширину выборки.

Хорошо, теперь мы знаем, как хранить документы и искать по ним в удобном графическом интерфейсе. Но как это вообще коррелирует с логами? Кто будет собирать их и класть в ES?

Для этого надо рассмотреть еще один инструмент, разработанный компанией Elastic, — Logstash. Из названия напрашивается цель инструмента — сбор логов для дальнейшего хранения, в том числе в виде документов в ES. Однако, в действительности, Logstash умеет намного больше — его задачей является сбор (input), обработка (filter) и отправка (output) логов на хранение. Как видно, напрашивается определенная аналогия с rsyslog и его модулями. И да, все правильно — концепт приблизительно такой с отличием только в формате передаваемых данных.

Отличительной чертой логов от других документов в ES является наличие поля времени отправки, по которому можно произвести сортировку событий и построить график поступления логов, это вы можете наблюдать на скриншоте выше. В остальном логи — это обычные документы, к которым применимы те же запросы для поиска и фильтрации.

Часто Logstash используют в роли инструмента обработки входящих логов в первозданном виде и их преобразования перед отправкой в ES, однако существуют и другие инструменты для выполнения этой работы. Связано это, в первую очередь, с тем, что Logstash, как и ElasticSearch, написан на Java - не самом ресурсобережном языке, из-за чего не принято ставить Logstash на каждой ноде для сборки логов.

Для этих задач у команды Elastic существует группа отдельных инструментов — Beats. Идея этих инструментов в том, чтобы создать маленькие инструменты, которые собирают конкретные данные и далее могут отправлять логи на обработку либо напрямую в ES, либо с предварительной обработкой Logstash.

Связку ElasticSearch, Logstash и Kibana принято называть ELK стеком - эдакое ванильное решение от одного разработчика, которое будет работать хорошо. Однако в реальности часто компонента под буквой L может быть заменена на другие, более производительные или гибкие решения.

К примеру, утилита fluentd, написанная на Ruby, позволяет выполнять задачи сборки, обработки и отправки логов куда угодно и практически в любом формате, благодаря модульному подходу этого инструмента и возможности установить необходимый конкретно для вас плагин, когда вам это нужно. Так, модуль fluent-plugin-elasticsearch позволяет отправлять логи в ElasticSearch.

Вместе с Fluentd мы получаем другую вариацию стека, которая используется достаточно широко, — EFK.

Разберем пример конфигурации fluentd:

<source>
@type tail
path /var/log/syslog
pos_file /var/log/fluentd-syslog.log.pos
time_format %Y-%m-%dT%H:%M:%S.%LZ
tag system
</source>
<match *.*>
@type copy
<store>
@type stdout </store>
<store>
@type elasticsearch
logstash_format true
logstash_prefix fluentd
flush_interval 10s
host "#{ENV['OUTPUT_HOST']}"
port "#{ENV['OUTPUT_PORT']}"
</store>

</match>

Согласно этому файлу, все логи из файла /var/log/syslog будут собираться и выводиться в вывод fluentd и в то же время — в ElasticSearch на удаленном сервере в индексы, начинающиеся на fluentd и заканчивающиеся на дату, когда был записан лог (и вот тут нам и может пригодиться Index Pattern в Kibana).

Хотя Fluentd является легким по ресурсам инструментом в сравнении с Logstash, он все равно может занимать мегабайт 20 на каждом из хостов (такова цена универсальности). Поэтому у Fluentd есть младший шустрый брат, полностью написанный на C, — Fluent Bit, у которого реализован фиксированный набор пакетов input и output. Важно то, что в отличие от Fluentd, Fluent Bit умеет отправлять в 2 вида серверов — Fluent(d/bit) (протокол Forward) и в ElasticSearch, что позволяет организовать каскад необходимой сложности для обработки логов.

Кроме оригинальной реализации ELK стека, в которой возможно использовать набор дополнений X-Pack (как бесплатную часть, так и платную), существует версия ElasticSearch и Kibana, освобожденная от проприетарных зависимостей и распространяемая под открытой лицензией. Эту версию называют Open Source (сокращенное OSS). Кроме нее, существует еще одна версия ElasticSearch, разрабатываемая компанией Amazon под названием Open Distro, которая приследует 2 цели:

В целом, все эти решения имеют право жить, однако в зависимости от того, как и в какой конфигурации вы устанавливаете стек, вам могут потребоваться те или иные ограничения/возможности, которые могут быть в разных версиях, бесплатно или платно.

Перед окончанием теоретической части хотелось бы упомянуть еще 2 инструмента, которые могут пригодиться вам при работе с ElasticSearch:

  1. Установите на вашем удаленном сервере Open Distro с доступом из интернета и настройте в нем доступ с Basic Auth данными open:distro.
  2. Установите на вашей виртуальной машине fluent-bit.
  3. Напишите конфигурацию для fluent-bit, которая будет отправлять все логи из файла /var/log/fluent на удаленный сервер в формате Logstash с префиксом fbit и автоматически генерировать идентификатор для сообщений
  4. На локальной виртуальной машине запишите в файл /var/log/fluent сообщение Mom, I'm in Kibana!.
  5. Проверьте наличие этой записи в логе через Kibana.
  6. На проверку отправьте URL для доступа к Kibana, время отправки сообщения и конфигурационный файл fluent-bit.

Технологический стек после практикума

Иконка linux

Linux

Иконка systemd

systemd

Иконка Keepalived

Keepalived

Иконка mdadm

mdadm

Иконка nginx

nginx

Иконка PostgreSQL

PostgreSQL

Иконка LVM

LVM

Иконка Ceph

Ceph

Иконка FreeIPA

FreeIPA

Иконка SSH

SSH

Иконка borg

borg

Иконка RabbitMQ

RabbitMQ

Иконка wireguard

wireguard

Иконка Graylog

Graylog

Иконка Prometheus

Prometheus

Иконка PowerDNS

PowerDNS

Иконка Grafana

Grafana

Иконка OpenVPN

OpenVPN

Иконка Redis

Redis

Иконка Apache

Apache

Иконка VNC

VNC

Иконка iptables

iptables

Иконка PHP-FPM

PHP-FPM

Иконка MariaDB

MariaDB

Иконка HAProxy

HAProxy

Иконка BIND

BIND

Иконка tinc

tinc

Иконка isc-dhcp-server

isc-dhcp-server

Иконка unbound

unbound

Иконка postfix

postfix

Иконка dovecot

dovecot

Иконка FTP

FTP

Иконка NFS

NFS

Иконка Samba

Samba

Иконка GlusterFS

GlusterFS

Иконка Netdata

Netdata

Иконка iSCSI

iSCSI

Иконка LXC

LXC

Иконка NFS

NFS

Иконка Libvirt

Libvirt

Иконка Docker

Docker

Иконка Zabbix

Zabbix

Иконка rsyslog

rsyslog

Иконка ElasticSearch

ElasticSearch

Иконка Fluentd

Fluentd

Иконка Kibana

Kibana

С какими задачами поступают к нам на практикум?

  • Освоить профессию системного администратора Linux
  • Научиться работать в консоли и познакомиться с основными сетевыми приложениями
  • Повысить квалификацию, продвинуться в должности и увеличить зарплату
  • Расширить свои технические навыки

Отзывы

@liquidpredator

Валерий Филлипов

  • 30 лет
  • Москва

До практикума: Системный администратор

После практикума: DevOps-инженер Fevlake

Работал админом у провайдера и понял, что мне это все становится не сильно интересно. Меня заинтересовал открытый урок по девопс. Пришел, послушал - понравилась подача Васи Озерова, и решил пойти дальше уже на практикум. А сейчас я еще и работаю в команде Васи - девопсом в Fevlake. Можно сказать, прошел практикум - сменил профессию.

Что запомнилось на практикуме? Отличные задачки. Некоторые заставляют прям посидеть - поразбираться. И это круто. Когда смотришь стандартные вебинары, где лектор долго что-то объясняет, уже через 15 минут засыпаешь. Здесь такого нет. Иногда так затягивала задача, что не замечаешь, как время прошло. Про время - тоже удачно придумано. Занимаешься, когда тебе удобно, очень удобно совмещать с работой и личными делами.

Обучение я бы порекомендовал любому системному администратору. Многие практики отсюда можно применять не только в девопсе. Для тех, кто разработкой занимается, много полезного в части понимания как будут разворачивать твой код. Да и вообще сюда стоит пойти всем, кому в принципе интересно развиваться и, конечно, тем, кто хочет сменить профессию

@ihlinilia

Илья Ильин

  • 32 года
  • Киев

До практикума: Системный администратор

После практикума: DevOps-инженер

Работал системным администратором и понимал, что уже достиг потолка. Хотелось двигаться дальше. Увидел информацию про практикум - понравилось, что программа в хороших сроках и спикер компетентный на открытых уроках. В самом практикуме тоже ни разу не разочаровался: понравился чисто практический подход. Все делали руками. Программа и база очень широкие. Нравилось, что задачки максимально приближены к реальности - всё из настоящих кейсов.

Да, изначально сомнения идти/не идти на практикум были, особенно по оплате - для Украины сумма немаленькая. Но брат выручил с деньгами. И могу сказать, что все вложения окупились. После практикума устроился DevOps-инженером в продуктовую компанию. Указал в резюме, что прошел практикум, и это сыграло в плюс - всем нравится, что ты вкладываешься в свое развитие.

Сейчас еще в REBRAIN пригласили на проверку заданий. Интересно заниматься с ребятами. Понятно, что весь материал я уже знаю, но когда кому-то объясняешь, сам заново погружаешься в тему, развиваешься.

Практикум я бы порекомендовал сисадминам, инженерам, тем, кто занимается поддержкой средней и большой инфраструктуры, и вообще всем, кто входит в профессию девопс. При должном рвении добьетесь!

@youmedv

Юрий Медведев

  • 28 лет
  • Москва

До практикума: Digital Marketing

После практикума: Junior DevOps

До практикума я работал в сфере Digital Marketing - удаленно занимался рекламой, маркетингом. Ранее работал инженером связи, от механика и до ведущего инженера, поэтому IT мне близко, и я всегда хотел развиваться в этом направлении, и вернуться в профессию. Потому заинтересовался открытым уроком по DevOps, который предложила мне таргетная реклама. После урока желание изучать DevOps усилилось - привлекли перспективы и сложная, но интересная работа. Так я решил пойти дальше на практикум. И уже в середине курса устроился в аутсорсинговую компанию по администрированию инфраструктуры и дорос до Junior DevOps.

Сам практикум - бомба! Намного круче классического формата с лекциями. Когда есть лекции, ты привязан к группе, ко времени. Здесь же отстать невозможно: включайся, когда удобно, и получай на любом этапе быструю обратную связь по всем заданиям. Выходит, как формат индивидуального практикума, но только еще и с возможностью постоянно находиться в сообществе - общаться, развивать кругозор.

После практикума меня позвали в команду REBRAIN как одного из лучших выпускников. И это тоже очень крутой опыт. Сейчас я курирую практикум - отвечаю на вопросы ребят, вместе разбираем задачи, что помогает укреплять знания, и разбираться в нюансах.

Сам формат, практикума с упором именно на выполнение заданий - именно то что нужно, чтобы сформировать достаточный кругозор и базис для развития. Так что, если тема DevOps или развития Operations Вам близка - практикум это именно то, что нужно!

@vk.com/musinaa

Айрат

  • 29 лет

До практикума: Системный администратор

После практикума: Junior DevOps

Я начинал свою карьеру с Линукса, поработал сисадмином и решил уйти в девопс. Привлекло то, что сейчас это везде, все держится на юникс. Кода много и перспектив много!

На базовый курс я попал одним из первых - в самый первый поток. Увидел рекламу практикума и побывал на первом занятии. Сомнений идти, или не идти практически не было, я был в первом потоке у ребят и мне показалось, что это больше плюс, потому что получится что-то свежее и интересное. Сейчас, когда я прошел базу, понимаю, что не прогадал. Да, не все с первого раза получалось, приходилось трудиться, "волшебных таблеток" никто не раздает. Но в итоге все получается! Особенно с такой поддержкой! С Василием Озеровым всегда можно было лично пообщаться, задать любые вопросы. Чат в Телеграм - вообще бомба! Да и в целом, понравилась экспертность Василия - без воды, все четко и сразу к делу. А еще круто, что нам дали сервер, на котором можно тренироваться и выполнять задания!

Информации на курсе было очень много и по деплою, и по непрерывной подаче кода. У меня сложилась полная картина, как работают Devops-практики, и теперь еще больше хочется погружаться в профессию! Тем более, что работу девопсом я уже получил.

@barm0leykin

Андрей

  • 37 лет

Девопс решил поизучать для себя - в работе точно пригодиться, и, возможно, в перспективе поможет выйти на новый уровень. И мое стремление всю эту тему поглубже узнать совпало с рекламой открытого урока, которую я случайно увидел. Я уже встречал подобные курсы, но мне понравился подход Василия Озерова - его подача материала.

Сейчас я еще на втором модуле практикума, о результатах говорить рано. Но пока нравится то, что задания грамотные, в нужной последовательности. Еще сразу видно, что все, что изучаем можно сразу же применять на практике. Ну и дополнительные видеолекции смотрятся легко, подача хорошая.

Еще один плюс - то, что даются аккаунты для работы, инфраструктурно решены многие вопросы. А значит, для практики не нужно дополнительно что-то искать, покупать. Бери и пробуй.

Практикум я бы посоветовал таким людям как я - системным администраторам, которые хотят получить опыт, расширить кругозор, и тем, кто занимается разработкой.

@SimWhite

Даниил

  • 36 лет

Сейчас все чаще стали использоваться новые технологии типа Ansible, и изучать их разрозненно достаточно проблематично. Потому я искал практикум, на котором все это можно освоить на практике - через конкретные задачи. Сходил на открытый урок к Василию Озерову, ну и, конечно, сравнил практикум с другими курсами. У многих акцент делается на теорию, а её я и сам могу изучить. Потому решил остаться на практикуме у Василия.

Приятно, что здесь есть документация, а дальше ты должен действовать самостоятельно. Многое приходится делать самому - а это реальная практика, как в жизни.

Обучение нравится, я даже знакомому уже порекомендовал - он системный администратор. Да и вообще практикум можно посоветовать всем, кто хочет развиваться и на практике пошагово изучать девопс

@bandikoot

Дмитрий

  • 24 года

После практикума: Junior DevOps

Я работал в госорганизацию с информационными системами. Технологический стэк там довольно древний. Понял, что хочется развития и работу решил сменить. Отсюда появилась и потребность в практикуме. Устроился системным администратором в компанию поддержки медиапортала и параллельно пошел учиться.

Практикум привлек изначально удачным сочетанием цена/качество, да и упором на практику. Еще понравилось, что тут комплексно все темы разбираются - складывается целостная картина. И еще всегда радует очень быстрая обратная связь по задачам, которым мы изучаем

В целом практикумом доволен и порекомендовал бы его людям моего уровня - тем, кто занимается системным администрированием и хочет развиваться. Также порекомендовал бы курс разработчикам, стремящимся развиваться в fullstack-development и желающим понять сторону Operations.

Получите консультацию по практикуму
или пройдите вступительный тест

Пройти тест

У нас практикуются сотрудники из

Лого Luxoft
Лого ВТБ
Лого НСПК
Лого Экспобанк

и другие

В конце вы получаете:

Иконка сертификата

Сертификат

По окончании практикума вам выдается электронный именной сертификат, подтверждающий, что вы успешно прошли все задания

Иконка Hard Skills Card

Hard Skills Card

После прохождения практикума вы получите Hard Skills Card. Карта компетенций отражает все ваши показатели по прохождению заданий и освоению технологического стека.
Hard Skills Card - ваша техническая карточка специалиста.

Клуб выпускников

После прохождения практикума и защиты финального проекта вы
попадаете в Клуб выпускников REBRAIN

Что включает в себя наш клуб?

  • Телеграм-чат для вопросов
  • Доступ к интересным вакансиям, которых часто нет на HH и в Телеграм-каналах
  • Приглашения на профессиональные мероприятия со скидками либо бесплатно
  • Сообщество ИТ-специалистов, в котором просто приятно пообщаться и поделиться новостями
  • Бесплатное участие в ежегодной конференции от REBRAIN

Авторы программы

Изображение автора

Дмитрий Дунаев

  • Ведущий DevOps-инженер международной компании JobLeads.
  • Более 5 лет опыта администрирования комплексных систем на базе ОС GNU/Linux.
  • Создал с нуля инфраструктуру для криптобиржи на Kubernetes.
  • Создал общий фреймворк для конфигурации серверов при помощи Ansible.
  • Постоянный ведущий открытых вебинаров Rebrain.
  • Автор заданий для практикумов DevOps, Docker, Kubernetes.
Изображение автора

Николай Хватов

  • Ведущий DevOps-инженер международной компании EPAM.
  • Более 8 лет опыта администрирования комплексных систем на базе ОС GNU/Linux, а также MS Windows Server.
  • Специализируется на облачных провайдерах (AWS, Azure, GCP), микросервисной архитектуре и контейнеризации, а также на CI/CD и IAC.
  • Реализовал несколько проектов в сферах Fintech и E-commerce на основе микросервисной архитектуры, Kubernetes и облачных сервисов.
  • Автор обучающих материалов в разделах Linux и Highload для Rebrain.
Fevlake лого

Команда инженеров Fevlake

С 2012 года мы упорно работаем над IT-инфраструктурами наших заказчиков с применением DevOps практик.

Fevlake.com

Администратор Linux как профессия

  • 2014 актуальных вакансий
  • Средняя зарплата - 90 000 рублей
  • 374 вакансии удаленной работы

Все задания, выполненные на практикуме, идут в ваше портфолио

Ваше резюме после прохождения практикума

Изображение пользователя

John Doe

Системный администратор Linux

Зарплата от 80 000 руб

Технологический стек

Навыки

  • Администрирование Linux серверов, систем на базе ОС GNU / Linux
  • Написание скриптов для автоматизации рутинных задач
  • Построение отказоустойчивых решений при помощи HAProxy, Keepalived
  • Построение инфраструктуры для микросервисной архитектуры с nginx, Apache, Docker MySQL, PostgreSQL, Redis, RabbitMQ
  • Настройка сетевой инфраструктуры (FreeIPA, DHCP, DNS) с нуля с автоматизированным разворачиванием серверов по сети при помощи PXE
  • Построение защищенных каналов для подключения к частной инфраструктуре при помощи различных VPN-решений (OpenVPN, tinc, WireGuard)
  • Построение системы мониторинга на базе Prometheus, Graylog и Grafana

Постподдержка и трудоустройство

  • Предоставим карту компетенций
  • Поможем составить актуальное резюме
  • Поможем подобрать интересный проект

Лучших пригласим
в команду Fevlake и Rebrain

Стоимость

40 000 руб.

Общая стоимость

4 000 руб/мес

Рассрочка 10 месяцев

Money Back 14 дней

Вернем средства без
объяснения причин

LifeTime Лицензия

Доступ к практикуму
останется с вами навсегда

Перейти к покупке
Иконки Linux

При одновременной покупке практикумов Linux.Basic +
Linux.Advanced общая стоимость – 65 000 руб.

Если вы хотите оплатить от юридического лица, мы составим договор и отправим вам на согласование.

40 000 руб.

Общая стоимость

LifeTime Лицензия

Доступ к практикуму
останется с вами навсегда

Money Back 14 дней

Вернем средства без
объяснения причин

Иконки Linux

При одновременной покупке практикумов Linux.Basic +
Linux.Advanced общая стоимость – 65 000 руб.

-40%

При приобретении нескольких программ,
получите скидку до 40% в личном кабинете

Часто задаваемые вопросы

В 2018 году мы провели 3 потока по системе 2-3 лекции в неделю + домашка. Со всех 3-х потоков мы собирали обратную связь, чтобы сделать практикум более эффективным и удобным для пользователей. И в каждом потоке мы видели, что ребятам недостаточно практики. Как дело доходит до ДЗ, сразу же возникает куча вопросов и непонятно, как выполнить задание. Тогда мы и пришли к тому, что двигаемся от практики, но подкрепляем это лекционным форматом. Поэтому ответ - Да, мы считаем наш формат практикума самым эффективным и подходящим для всех. Если вдруг формат вам не подойдет, в первые две недели вы можете полностью вернуть средства без объяснения причин.

При загрузке 4-6 часов в неделю вы пройдете все задания за 7 месяцев. Вы занимаетесь онлайн в удобное для вас время, без привязки к конкретной дате и получаете обратную связь кураторов по вашим заданиям в течение 24 часов. Смотреть теоретические видеоматериалы можно по очереди или все сразу.

Да, вы оплачиваете практикум полностью официально, с договором публичной оферты можно ознакомиться внизу страницы.

Мы предоставляем 2 рассрочки от банков-партнеров - Тинькофф и Альфа, у них идентичные условия: 0 рублей первоначальный взнос, ежемесячный платеж на 10 месяцев 3800 рублей (после окончания скидки – 6000 рублей), комиссий, штрафов и скрытых платежей нет. Все расходы на обслуживание мы берем на себя. Полностью внести остаток и закрыть рассрочку можно в любой момент, также без штрафов. Чтобы оформить рассрочку нажмите на кнопку «Рассрочка» в блоке «Стоимость».

Да, конечно, мы полностью белая организация. Для того, чтобы оплатить практикум от юридического лица, вам необходимо отправить ваши реквизиты с помощью формы «Плачу от организации» на сайте.

Мы понимаем, что мы все разные, и кому-то может не подойти наш формат, поэтому мы даем возможность в первые 14 дней практикума сделать возврат средств без объяснения причин. Причем вернуть можно и при единовременной оплате и при оформлении рассрочки от банка.

Да, вы проходите задания на нашей инфраструктуре. Вам не потребуется ничего докупать дополнительно.

Связаться с нами

Мы разработали инновационную модель онлайн-практикумов для IT-специалистов. Через полное погружение в практику и решение реальных кейсов мы помогаем ребятам из любой точки мира получить востребованную профессию.

Международное агентство Devops-практик. Занимаемся проектированием и обслуживанием IT-инфраструктур с 2012 года. Наши клиенты: IMPROVE MEDIA, КупиКупон, CRYPTO EXCHANGE, NEWS360 и др.

Получить персональную скидку 5 000 руб.