практикум

LINUX

by rebrain

Онлайн-практикум от команды Fevlake, 8 лет обслуживаем IT-инфраструктуры различных компаний

90% практики

Онлайн-практикум для освоения Linux

45+ заданий

Выполни все задания и начни работать
системным администратором Linux в
российских и международных проектах

Онлайн-
практикум

Проходите, когда вам удобно

посмотреть уровень basic >>>

статистика
в цифрах

ТОП 1

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

90 000 руб.

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

2014

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

*по данным
Hh.ru

Технические специалисты любят Linux Это
одна из самых популярных операционных систем среди разработчиков, Давайте посмотрим, насколько:

Статистика Linux:

96,3%

Из 1 миллиона лучших серверов
в мире работают на Linux

36,7%

Cайтов с известными операционными системами используют Linux

54,1%

Профессиональных разработчиков используют Linux в качестве платформы в 2019 году

83,1%

Разработчиков говорят, что Linux —
это платформа, на которой они
предпочитают работать

100%

Из 500 лучших суперкомпьютеров
мира работают на Linux

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

как
проходит?

start here

Получаем задание

01

Читаем наш материал для его выполнения

02

Если есть вопросы, задаем команде кураторов

03

Выполняем задание, если есть вопросы, смотрим материалы

04

За 24 часа получаем развернутый комментарий проверяющего

05

Вносим правки

06

Переходим к следующему заданию

07

почему
rebrain?

Стажировка и практика

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

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

если есть вопрос по заданию, спросите у
авторов практикума и экспертов в закрытом
чате Telegram

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

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

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

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

более 45
задач

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

Чат с авторами

И действующими
специалистами в
облачной архитектуре

Финальный проект

полный кейс реального проекта Linux,
который идёт в ваше портфолио

Реальные задания

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

после прохождения практикума уровня advanced вы можете проходить сертификацию администратора linux уровня LPIC-2

кому подходит?

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

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

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

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

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

  • MariaDB
  • PostgreSQL
  • Redis

  • Basics
  • Proxy, access
  • Conditions, regex

  • Apache
  • PHP-FPM
  • Let's encrypt

  • HAproxy
  • Keepalived
  • OpenVPN
  • Pritunl
  • Tinc
  • Wireguard
  • Ocserv
  • BIND
  • Unbound
  • PowerDNS
  • DHCPD
  • dnsmasq
  • PXE

  • GPG
  • Package repository
  • LXC
  • Libvirt
  • Docker
  • FreeIPA

  • rsync
  • borg

  • FTP
  • NFS
  • Samba
  • iSCSI
  • Glusterfs
  • Ceph

  • Postfix
  • Dovecot

  • Netdata
  • Zabbix
  • Prometheus
  • Grafana

  • logrotate
  • Syslog
  • Rsyslogd
  • EFK
  • 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 - позволяет в интерактивном режиме задать все параметры создаваемого ключа:

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

После этого производится ввод парольной фразы (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) <docker@docker.com>

sub rsa4096 2017-02-22 [S]

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

uid [ultimate] test@user.com <test@user.com>

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

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

uid [ultimate] qwerty <qwerty@name.co>

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] test@user.com <test@user.com>

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

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

uid [ultimate] qwerty <qwerty@name.co>

ssb rsa2048 2020-07-01 [E]

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

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

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

  • gpg --export 0A2314DCBF13E2068D465521ABFA559546CFCD04
  • gpg --export qwerty
  • gpg --export qwerty@name.co

Одно но - данный файл экпортирует в бинарном виде, который можно сохранить через перенаправление потока, но не скопировать текстом. Для того, чтобы можно было это передать, в читаемом и копируемом виде, можно воспользоваться флагом --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 <qwerty@name.co>" not changed

gpg: key ABFA559546CFCD04: secret key imported

gpg: Total number processed: 1

gpg: unchanged: 1

gpg: secret keys read: 1

pg: secret keys imported: 1

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

$ gpg --import /tmp/qw

gpg: key ABFA559546CFCD04: "qwerty <qwerty@name.co>" 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). test@user.com <test@user.com>

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). test@user.com <test@user.com>

gpg>

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

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

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

  • --encrypt --recipient $RECIPIET_ID - позволяет зашифровать сообщение при помощи публичного ключа конкретного ключа
  • --symmetric - зашифровать при помощи passphrase, которая будет запрошена в интерактивном режиме

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

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

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

Сгенерируйте ключ при помощи флага --gen-key (команды и вывод сохраните)
Выведете список публичных и приватных ключей (команды и вывод сохраните)
У созданного ключа удалите дату истечения (команды и вывод сохраните)
Выведете список публичных и приватных ключей (команды и вывод сохраните)
Экспортируйте публичный ключ в файл в ASCII формате и выведете его (команды и вывод сохраните)
Экспортируйте приватный в бинарном виде в файл (команду и вывод сохраните)
Зашифруйте строку RebrainMe Linux ASYM при помощи сгенерированного ключа в ASCII формате и выведете этот файл (команды и вывод сохраните)
Зашифруйте файл с приватным ключем при помощи passphrase secret в ASCII формате и выведете этот файл (команды и вывод сохраните)
Удалите из вашего хранилища публичный и приватный ключ (команды и вывод сохраните)
Выведете список публичных и приватных ключей (команды и вывод сохраните)
Расшифруйте приватный ключ и импортируйте одной командой (команды и вывод сохраните)
Выведете список публичных и приватных ключей (команды и вывод сохраните)
Расшифруйте файл с зашифрованной строкой (команды и вывод сохраните)
Отправьте на проверку все сохраненные выводы

Интернет - это глобальная сеть, через которую можно получить огромное количество данных, начиная от видеопотока с вашими друзьям и родственниками, заканчивая корпоративными данными с вашего места работы. Наиболее распространенным окном в Интернет является браузер, через который отрисовывывается вся эта информация. Однако если то, как пользоваться браузером, сейчас понятно почти каждому, то какое приложение отдает нам контент из интернета - более широкая тема. В рамках этого и последующих блоков мы будем разбирать инфраструктурные компоненты один за одним, чтобы у вас сформировалось как понимание, так и опыт работы с ними. Начнем мы с 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.

Это задание выполняется на виртуальной машине, которую Вы создаете самостоятельно на инфраструктуре Ребрейн. Необходимая информация и инструкции размещены на вкладке "Инфраструктура" (просьба строго соблюдать). Для создания/удаления виртуальной машины Вы можете использовать любой знакомый Вам инструмент (например, Terraform) или утилиту hcloud.
Пример использования 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
Установите пакет nginx-full.
Напишите конфигурационный файл nginx, который реализует следующую функциональность:
Отключен модуль 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.
В ответе пришлите:
конфигурационный файл для основного сервера и путь до него; список файлов в /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

}

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

  • Мы отправили запрос методом PUT по пути /blog/post/1, тем самым определив индекс (_index) blog, тип сообщения (_type) и идентификатор сообщения (_id) - 1.
  • В теле (JSON) мы описали объект, в котором есть 4 поля - title, content, tags, cuteness и published_at. У каждого из них свой тип и это важно (текст, текст, массив строк, число и дата).

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

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

Example img 1

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

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

  • котята — простой запрос без использования полей;
  • title:"Веселые котята" — позволит получить документы, в title которого присутствуют слова из переданной строки;
  • tags:котята — вернет документы, у которых в массиве tags есть котята;
  • cuteness: [6 TO *] — найдет все документы, у которых милашность выше 6;
  • NOT tags:песики — отфильтрует из выборки документы, у которых в массиве есть песики;
  • tags:котята AND cuteness: [6 TO *] — объединение двух условий (AND — требует от документа подходить по двум правилам, а OR — хотя бы по одному).

Кроме формата запросов по умолчанию, который пришел в 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 цели:

  • обойти лицензионное ограничение на использование ElasticSearch в режиме Hosted solution (что запрещено лицензией оригинального продукта);
  • сохранить возможности X-Pack в том или ином виде для удобства.

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

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

  • curator — позволяет управлять жизненным циклом индексов в ElasticSearch (к примеру, настраивать ротацию индексов с необходимой глубиной). В последних версиях часть этой функциональности можно возложить на Kibana c X-Pack или Open Distro.
  • cerebro — своеобразный административный кабинет по работе с ElasticSearch. Позволяет удобно работать с индексами, шаблонами индексов и другими компонентами вашего ES кластера.

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

в процессе
вы изучите

  • Linux, systemd, Keepalived, mdadm, nginx, PostgreSQL, LVM, Ceph, FreeIPA, SSH, borg, Redis, RabbitMQ, ireguard, Graylog, Prometheus, PowerDNS, Grafana, OpenVPN, Apache, VNC, iptables
  • PHP-FPM, MariaDB, HAProxy, tinc, isc-dhcp-server, unbound, postfix, FTP, dovecot, NFS, Samba, BIND, Kibana, GlusterFS, Netdata, iSCSI, LXC, NFS, Libvirt, Docker, Zabbix, rsyslog, ElasticSearch, Fluentd.

с какими задачами приходят на практикум?

Освоить профессию системного администратора Linux

01

Научиться работать в консоли и познакомиться с основными сетевыми приложениями

02

Повысить квалификацию, продвинуться в должности и увеличить зарплату

03

Расширить свои технические навыки

04

Отзывы

Юрий / 28 лет

Digital marketing >>> Junior DevOps

@youmedv

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

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

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

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

Сергей / 32 года

Junior DevOps

@KernelVrn

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

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

Наталья / 32 года

Support Engineer

@Natalia_mm

Практикум я решила проходить как дополнение к текущей работе. Хотелось изучить все инструменты DevOps в целом. Например, по работе мне был нужен Docker. Мой коллега проходил практикум DevOps by Rebrain, и он рассказывал, как это круто, и что можно в случае, если не подойдет, вернуть деньги в течение 2 недель. Я заинтересовалась и решила попробовать.
Я очень боялась, что не пройду по стартовым знаниям, все-таки я совсем не системный администратор. Но проблем у меня не было. Все есть в гугле. Если нужно что-то сделать и не знаю как, то просто открываю гугл и ищу. Считаю, что это необходимость такого формата, как практикум. За то время, что его прохожу, уже добавила себе определенную базу знаний по разным темам. Сейчас прохожу практикум не спеша, 1-2 задания в неделю, периодически делаю перерывы. Очень нравится за счет того, что это практика, нет скучных лекций. Василий Озеров проводит позитивные, классные мастер-классы. На мой взгляд, цена практикума совершенно адекватна.
Из пожеланий - хотелось бы улучшить SLA. И есть некоторые задания в модуле DevOps, где сложно понимать формулировки. Из моментов, что нравятся, это - очень большое количество инструментов, которое нужно при работе с практикумом. То, что задачи близки к “боевым”. Хорошо, что могу заниматься, когда хочется, без привязки ко времени. Мне не подходит время мастер-классов, чтобы смотреть их онлайн, тут есть возможность посмотреть их в записи.
Отдельно хочется отметить обаяние Василия. Он так просто рассказывает сложные вещи, что кажется, и я, и любой другой так сможет.

Я рекомендовала бы практикум системным администраторам, заинтересованным в автоматизации.

Руслан / 34 года

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

@Ruslan Zuiev

Решил изучать Linux т.к. мне нравится открытая идеология этой ОС и я давно хотел работать на должности, связанной с настройкой ОС.
На практикуме Rebrain в итоге остановился, в первую очередь, благодаря менеджеру Александре, которая дала мне профессиональную консультацию относительно практикума, чётко отвечала на все вопросы. Также, в сравнении с конкурентами, Rebrain позволил мне самому выстраивать график обучения, а не как у других, выдавать информацию маленькими порциями, чтобы растянуть курс на длительный срок.
Но я не был уверен в состоятельности практикума, т.к. ни один человек на тот момент не прошел его полностью. В итоге, я настолько доволен практикумом, что считаю, что там всё так и должно быть. Только сертификат хотелось бы более презентабельный, чтобы можно было на стену повесить. Особенно отмечу возможность выполнять сразу несколько заданий в день, отзывы кураторов, саму структуру практикума.
Рекомендовал бы практикум людям, которые любят решать «загадки» и им нравится работать за компьютером.
Спустя пару недель подготовки подготовки к собеседованиям и составления резюме (с этим, кстати, опять же очень помог Rebrain!) я получил 2 оффера от международных компаний. В итоге, из них я выбрал ту, работа в которой более связана с моим запланированным направлением - DevOps. Как оказалось, не зря я дополнительно занимался английским языком, это стало дополнительным и очень важным скилом в поиске работодателя.
На этом не планирую останавливаться и хочу уже в скором времени приобрести курс DevOps by Rebrain, чтобы поскорее освоится на новом рабочем месте и ускорить свой прогресс. Тем более, если я не ошибаюсь, Rebrain предоставляет скидку "постоянным покупателям" :)

Айгерим

@baigabul

Можно я скажу большое человеческое спасибо за ваш труд и практикумы.
Не могу молчать уже 😂 Ещё мне далеко до конца их, но блин, благодаря им кучу нового узнала и уже сижу девопсом.
Спасибо ребятам, которые запросто отвечают на вопросы, даже если не по заданиям.
Купила их просто так, от нечего делать, немного заскучав в дба. А теперь вот сижу много на работе, но очень круто и интересно. Многие многие вещи с практикума и вебинаров очень пригодились. Спасибо))

Сергей

Архитектор по информационной безопасности

@SergeyErmakov

На практикум пошел, потому что захотелось уложить в голове разрозненные знания по современным информационным технологиям типа Kubernetes, Docker. Сначала увидел статью на хабре, посмотрел один открытый практикум с Василием. После него мне начали регулярно приходить письма с предложением пройти практикум. Сначала мне это было неактуально, но письма с седьмого я все таки решил записаться. Из плюсов для меня - то, что используется реальная инфраструктура и приближенность заданий к реальности.
Многие вещи я уже знал, практикум помог их систематизировать. Но могу сказать что кривая практикума в некоторых заданиях все же крутовата. Из разряда - вот тебе винтик и гаечка, теперь собери из них самолет, иногда не хватает промежуточных шагов. Я уже и так знаю, как сделать быстро и неправильно, а хотелось бы узнать правильные пути.
Хотелось бы больше обратной связи и более прямой помощи от кураторов. Иногда их объяснения в чате слишком непрямые и недостаточно подробные. Я понимаю, что таким образом кураторы пытаются всеми силами подтолкнуть к поиску решения самостоятельно, но иногда все таки стоит указать прямо в ответ, ученик меньше времени потеряет.
В целом, практикум полезен мне для работы - лучший способ взаимодействовать с DevOps инженерами и администраторами, понимать подробности их деятельности. Рекомендовал бы практикум человеку, который с технологиями представленными в нем, напрямую не работал, - он будет полезен эникейщикам, безопасникам, сисадминам.

Иван

Системный администратор >>> Junior DevOps Engineer

@Skensel

Я перешел на Junior DevOps Engineer меньше месяца назад. До этого был системным администратором. Практикум дал большой толчок для моего роста как технического специалиста.
Раньше увлекался программированием, но понял, что это не мое, меня больше интересовала работа с инфраструктурой и автоматизацией. Два года назад начал узнавать что же это такое "DevOps". А год назад уже взялся за изучение инструментов и практик.
Сперва занимался саморазвитием, но зашёл в тупик и не мог понять как применять полученные знания. На Ютубе наткнулся на открытые практикумы Василия Озерова. Понравилось, как Василий рассказывает лекции и сразу показывает живые примеры. Позже начал искать информацию о практикуме. Примерно месяц думал, потом купил доступ.
Преимущества формата практикума - то, что это именно практикум, задания чисто практические. Можно заниматься, когда тебе удобно. Нет жестких рамок в виде лекций. Когда возникает проблема, можно спросить у куратора. Если задаю вопрос, обратная связь приходит быстро. Сейчас я прежде всего делаю упор на вещи, которые пригождаются в работе.
Практикум подойдет как программистам так и системным администраторам желающим получить новые навыки или карьерные движения. Практикум стоит своих денег и уже окупается:)

Сергей / 47 лет

Начальник отдела ИТ >>> DevOps-инженер

@rasdva3

В первый раз я наткнулся на открытый практикум Rebrain примерно в начале 2019 года. Первые впечатления: круто, мало что понятно, нужно разбираться, хочу еще. Направление выбрал из-за личного интереса и денежной мотивации. Работал я тогда начальником отдела информационных технологий в одной коммерческой организации и первой мыслью у меня было — надо брать, а лучше затаскивать на этот курс еще как минимум одного из моих бойцов. Но руководство обучение не поддержало, а стоимость единственного тогда курса DevOps была выше моей месячной зарплаты. Тогда я взял паузу на несколько месяцев… Регулярно смотрю открытые практикумы, облизываюсь на суммы зарплат, которые мелькают на hh.ru. И вот в последнюю пятницу июля 2019 года я решил — беру практикум DevOps! Квалификацию нужно повышать, а спасение утопающих — дело рук самих утопающих. Тем более на мой взгляд, альтернатив практикуму DevOps by Rebrain просто нет. Главное его преимущество — много практики.
Прошло почти полтора года с тех пор, как я впервые сделал пуш в свой репозиторий на gitlab.rebrainme.com, и каковы результаты:
- DevOps: 60%
- Docker: 100%
- Kubernetes: 80%
- Резюме на hh.ru, профиль на LinkedIn, регулярно читаю @devops_jobs
И вот оно! — «Здравствуйте, ваш опыт нас заинтересовал». Созваниваемся с HR, затем с руководителем департамента программных решений, на следующий день мне говорят, что меня берут, и на пятый день после первого звонка я уже работаю в проекте, с оплатой почти в четыре раза большей, чем на прошлом месте работы. И вот уже полтора месяца я фигачу как полноценный devops engineer (одна штука) в команде разработки.

Александр / 32 года

Специалист технической поддержки

@mrDuglas42

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

Евгения / 40 лет

Разработчик

bagdenia@mail.ru

У нас все в кубере с хельмом, поэтому нужно быть в теме. На работе предоставили такую возможность, и я сразу согласилась пройти практикум.
Мне понравился курс, но я бы рекомендовала привести конспекты в соответствие с видео, либо удалить их вовсе ) После просмотра видео когда приступаешь к заданию, удобнее было бы ориентироваться в тексте, а не искать по видосу. А в тексте во многих уроках нет и половины нужной информации, чем ближе к концу — тем меньше.
В курсе доступное и подробное изложение практических аспектов, приятное итоговое задание.
Рекомендую практикум разработчику, который “на вы” с кубером, но уже имеет представление о контейнерах, оркестрации и иже с ним.

Евгений / 34 года

Разработчик

@eugeneshumilin

Технологии Kubernetes x Yandex Cloud используются на текущем месте работы, мне в компании предложили пройти практикум от REBRAIN, чтобы систематизировать и углубить знания. Я опасался, хватит ли времени, но решил попробовать.
Программа мне понравилась. Хотя возможно было бы здорово немного переписать формулировки домашнего задания, чтобы было более четко и понятно. Особенно ценными в практикуме для меня были helm и итоговое задание. Да и качество материала в целом на высоте.
Я с охотно рекомендую курс другим бэкенд-разработчикам.

Сергей / 26 лет

DevOps-инженер

@Josers

Давно уже решил выбрать это направление, записался на курс Kubernetes x Yandex Cloud для систематизации обобщения знаний. У REBRAIN мне нравятся открытые практикумы, редко посещаю, но темы крутые.
На курсе понравилась концентрация контента, интересные задачи, автопроверки. Рекомендую пройти практикум или админу, или разработчику, который начинает работать по данным методологиям. Курс хорошо дает представление о процессах и работе. Также человеку, который бы хотел попробовать себя в роли DevOps-инженера.

Дмитрий / 44 года

DevOps-инженер

dduchin@mail.ru

Мне хотелось проверить свои знания по Kubernetes x Yandex Cloud и приобрести новые. Поэтому когда мне предложили пройти практикум — согласился, сомнений не было. Я остался доволен, считаю, что программа стоит своих денег. Что особенно понравилось:
1. На видео очень хорошее описание тем ну и просто хорошо и качественно сделано.
2. Быстрая проверка при выполнения задания.
3. Можно проходить темы в любое время — нет очень жестких ограничений и сроков обучения. Даже жаль, что обучение закончилось))
Поэтому с удовольствие рекомендую курс всем, кто хочет поменять свое профессиональное направление.

Денис / 35 лет

Тимлид

Kuber используется в инфраструктуре компании, а у меня не было знаний по нему до практикума. Мне предложил пройти курс Kubernetes x Yandex Cloud от REBRAIN работодатель, а я сомневался оправдается ли потраченное время. Но по итогу я остался доволен.
Программа даёт достаточные первичные знания после прохождения. Хотя у меня возникло несколько организационных вопросов: например, я не сразу попал в группу, не сразу мог начать и в итоге оставался 1-1,5 месяца на прохождение, было бы лучше если ограничение было не 3 месяца, а 6. Считаю, что данный курс будет полезен начинающим DevOps.

Артемий / 30 лет

Разработчик

Мне хотелось плотнее познакомиться с инфраструктурными решениями, которые используются в нашей компании. Работодатель выбрал практикум за меня, хотя перед стартом программы меня пугали сложность K8S, совершенно незнакомая платформа Yandex.Cloud и распределение объёма работ по времени. Но курсом я остался доволен.
Хотя хотелось бы больше именно практических вещей (например, сделать сайт с использованием Ingress, Deployments и оператора БД).
Большая часть курса объяснена очень понятно, с примерами и ссылками на документацию. Выбор Yandex.Cloud позволил посмотреть возможности K8S по масштабированию на несколько узлов.
В программе были рассмотрены темы "повышенной сложности" (и полезности), такие, как helm.
Я могу рекомендовать этот практикум разработчикам или DevOps, которые хотя углубить знания по Kubernetes x Yandex Cloud.

Станислав / 40 лет

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

Я знал, что Kubernetes x Yandex Cloud может пригодиться в работе, и практикум от REBRAIN мне посоветовали коллеги. Сомнений не было, я сразу решил проходить именно его.
Курс мне понравился. Отличные дабораторки, хорошо структурированный материал. Удобный формат без привязки ко времени. Единственный минус — слабая поддержка Windows. Это вызывает некоторые затруднения при выполнении лаб.
Рекомендую этот практикум всем, кому нужно разобраться в теме.

Александр / 33 года

Ведущий инженер-программист

@berem

Большую часть своей карьеры я провел в админах. Сейчас догоняю знания - и по программированию, и по технологиям.
Почему выбрал Девопс? Так сошлись звезды. Эта сфера мне интересна, хочу в ней развиваться.
Когда выбирал практикум, сомнения были, и финансовые, и определенный скепсис к онлайн-практикуму. Поэтому присматривался к практикуму очень давно, был на бесплатных практикумах Василия Озерова. После них и решил, что это мое. К покупке подтолкнуло появление рассрочки, тогда и понял, что пора вкладываться в свое образование.
Практикум очень сильно нравится. Меня очень сильно заинтересовал формат. До этого был на курсах, где только лекции. А здесь именно практические занятия. Теория без практики - это ничто.
Начальных знаний для старта практикума хватило, влился быстро и мне было интересно.
Сейчас иногда удивляюсь людям, которые не нравится такой формат. Я наоборот рад, что нужно много копаться самому. Ищешь информацию и сам развиваешься в процессе поиска. Мне кажется, иначе ничего не запоминается и когда столкнешься с задачей в работе, начнешь все искать с “чистого листа”.
Замечательно, что в практикуме нет ограничения по времени и ограниченных сроков. Хотя кому-то это может быть сложно - ведь тут контролируешь себя сам.
Конечно, встречаются задачи, которые прямо не хочется делать. Ходишь вокруг нее день-два, а потом соберешься и делаешь за час. Если бывают какие-то недопонимания по заданиям, то кураторы всегда подскажут.
Из пожеланий - хотелось бы больше заданий по облакам, Google Cloud и Amazon Cloud.
Практикум прохожу с июня, сейчас прошел почти до конца. В сентябре ходил на собеседование на DevOps-инженера. Мне сказали, что нужно подтянуть знания по технологиям и английский язык. В январе сходил повторно и получил оффер на зарплату в два раза большую, чем у меня сейчас. Поэтому финансовыми вложениями в прохождение практикума доволен. Осталось получить 1 сертификат и буду переходить на новую работу.

Практикум подойдет админам и программистам, заинтересованным в автоматизации рутинных операций.

Илья / 28 лет

Старший системный администратор >>> DevOps-инженер

@ilbka

Хотел изучить Кубернетес, так как эта технология очень востребована. Увидел рекламу бесплатного практикума Rebrain, поучаствовал в нем. До этого уже был опыт обучения от mail.ru, поэтому был поражен, насколько выше уровень Rebrain, даже на бесплатных занятиях.
Для моего региона цена практикума достаточно высокая. Но теперь совершенно не жалею потраченных денег, жалею только, что не пошел на практикум раньше.
Понравилось, что материал составлен грамотно, были интересные кейсы, практикум полностью готовит к сдаче экзамена по куберу. Хотелось бы субтитры к материалу (так как много материала на английском) и более развернутой обратной связи от кураторов.
Практикум будет полезен любому сисадмину, который хочет достичь чего-то большего.

Анатолий / 34 года

Системный администратор >>> Системный архитектор

tolik8621@list.ru

DevOps-практиками заинтересовался за счет необходимости иметь широкий кругозор. А так же нравиться их идеология, то есть необходимость плотного взаимодействия различных команд.
Практикум Rebrain выбрал из-за уклона в практическую часть. Сомневался, пригодятся ли полученные знания и не потрачу ли я время в пустую. Это сомнение отмел, так как любые инвестиция в себя полезны. Было сомнение о качестве заданий. Будет ли они достаточно хорошо проработаны. Его так же отмел, все хорошо. Думал, стоит ли связываться с рассрочкой, ну это сугубо личное не желание связываться с кредитами и т.п. Сейчас рассрочку уже закрыл, сомнение снято.
Практикум нравится. Особенно уклон в практику, видео от Василия Озерова, получается строго лаконично и по делу. И то, что проверяющие заинтересованы в качественной проверке, дополняют твои ответы комментариями
Мне кажется, стоит SLA для повторных попыток сделать 12 часов, но по всей видимости сейчас это не реализуемо. Проверяющих не хватает и так.
Ну а так в общем все хорошо, к формулировкам заданий вопросов нет. Мне кажется это сделано намеренно чтобы посмотреть как человек мыслит и до чего дойдет в своих рассуждениях. Можно так же задать уточняющий вопрос проверяющему, не вижу проблем, либо обсудить с ним спорный момент, это работа с людьми и это нормально.
Рекомендовал бы практикум наверное администраторам, для расширения кругозора, да в общем и программистам тоже.

Артём / 33 года

Начальник направления

@ArtemNemesis

Я использую k8s в повседневной работе, поэтому, когда Yandex Cloud предоставил скидку, сомнений идти ли курс не было. Мне очень понравился курс, и я рекомендую его тем, кто интересуется темой. Отличный практикум, все очень доходчиво. Единственное, в финальном задании я бы предложил более подробно расписать, какой ответ нужно получить от ПО. А также рассказать про Hashicorp Vault рядом с gpg шифрованием и добавить его использование в финальном задании.

Денис / 34 года

СТО

@den22ru

Мне нужен был практикум для понимания и проектирования архитектуры. Очень подкупало, что в курсе много практические занятий, но казалось, что он очень дорогой. Но по итогу я не пожалел, что его купил и прошёл.
Да, где-то библиотечки из заданий устарели, и новые версии уже не работают по тем шагам, что указаны в задании, но это не испортило впечатления. Понравились практические занятия, я получил очень много сопутствующих знаний. Рекомендую программу начинающим DevOps, а также middle и senior разработчикам.

Валерий Гусев / 58 лет

ИТ-архитектор предприятия (Enterprise architect)

gusev_vv@magnit.ru

Компания активно развивает применение облачных технологий Яндекс и, в частности, kubernetes. Поэтому для систематизации знаний и оценки потенциала предлагаемого курса для сотрудников компании я прошел практикум от REBRAIN. Выбрал его, так как он является частью многокомпонентного курса, который предложил Яндекс. А у REBRAIN высокая репутация на рынке обучения.
Перед началом программы сомнения были следующие:
1. Отсутствие свободного времени.
2. Напряжение вызвала необходимость указывать сотовый телефон (персональные данные).
Других сомнений предложенные условия не вызвали.
Мне понравилось, хотя на мой взгляд процесс построен излишне академично. Т.е. инструктор старается побудить студента к довольно объёмной самостоятельной работе, не даёт знания, а подталкивает к их поиску. Это правильно, но излишне трудоемко. Обычно, коммерческие курсы по технологиям рассчитываются на 5 дней, в такой манере преподавания в 5 дней точно не уложишься. И это минус, так как времени у сотрудников коммерческих компаний мало.
Ещё раз хочу подчеркнуть своё впечатление, что инструктор старается, что бы студент усвоил курс, но для этого часто нужно затрачивать слишком много времени, а его нет. Поэтому я считаю, что в чём-то необходимо студента просто наталкивать на решение.
Второй момент — контрольное задание требовало определенных знаний продуктов Postgre и RabbitMQ, продукты же в курсе не рассматривались. Это не очень хорошо, так как потребовало самостоятельного изучения этих продуктов.
Но в целом от курса и персонала остались хорошие впечатления. Спасибо! Курс рекомендую своим знакомым и техническим сотрудникам компании. Полнота материала, организация и люди на высоте. Курс будет полезен разработчикам, DevOps, системным инженерам инфраструктуры.

Игорь / 44 года

DevOps-инженер

Я использую материал в работе, рассматриваем применение Kubernetes. Пройти курс мне предложил Яндекс. По условиям партнерки, курс был ограничен по времени, и я опасался не уложится в сроки. Но по итогу я всё успел, и мне понравилось.
Встречались мелкие неточности вроде изменившегося названия роли в Yandex Cloud, но в общем это всё додумываемо и решаемо. Ещё один минус, который удалось впомнить — в задании KUBxYC-34 все необходимые компоненты "со скрипом" умещаются в кластер, не сразу удалось поднять всё, пришлось ужимать по памяти.
Но видео хорошие, хороший докладчик. В целом всё хорошо.
Я рекомендую практикум админам, начинающим девопсам, интересующимся k8s и сопутствующими инструментами.

Илья Карпов / 34 года

Разработчик

Мы переезжаем на кубер в облако, поэтому работодатель оплатил мне курс для повышения квалификации. У меня очень мало времени, перед началом программы я очень сильно сомневался, что мне хватит 2х недель, чтобы закончить. Ведь у меня был только 1 час времени перед работой. Но по итогу я прошел программу и остался доволен. Для улучшения могу предложить следующее:
1. Рассказать про шаблоны оператор, сайдкар.
2. Добавить про service mesh.
3. Рассказать про disaster recovery зонального кластера.
Но самое главное, что и так есть в курсе — это практика, практика и ещё раз практика. Времени на прохождение мне хватило. Я рекомендую пройти курс всем middle software engineer+.

Альберт Ковальчук / 47 лет

Разработчик

Я выхожу на архитектора, и мне было полезно в работе укрепить свои знания в Kubernetes x Yandex Cloud. Коллеги дали промокод на программу REBRAIN, и я решил не упускать возможностей. Сомнений проходить её или нет — не было, и я не пожалел.
Я бы рекомендовал немного расширить программу, некоторые темы хотелось пройти чуточку подробнее. Но самое главное, в практикуме — минимум воды, практичные обучающие видео. Я доволен тем, что прошёл обучение, и рекомендую его всем разработчикам.

Даниил / 29 лет

Руководитель отдела

Сервисы в моей компании развернуты в Kubernetes в Yandex Cloud, поэтому я хотел расширить свои знания. Программу предложил менеджер из Yandex Cloud, и я решил попробовать. Хотя и опасался сначала, что получу перевод документации, что это будет не интересно и не запомнится.
Курс мне понравился. Хотя кое-где надо обновить материалы. Здорово то, что для решения некоторых задач приходится не только действовать соразмерно материалам, но и дополнительно гуглить и углублять знания. С удовольствием рекомендую практикум админам, DevOps, SRE и backend разработчикам.

Рамиль / 27 лет

Разработчик

На сегодняшний момент любой бекенд-разработчик обязан знать как работает кубер, это must have. Мне курс рекомендовали знакомые. Я опасался, что:
1) Будут длинные видео с объяснением материала.
2) Будут скучные домашки.
3) Будет много теории и мало практики.
Но по итогу все опасения оказались напрасны. Особенно понравилось:
1) Итоговое задание.
2) Развертка собственного кластера с нуля.
3) Материал про helm.
Рекомендую курс любому DevOps-инженеру и бекенд-разработчику.

Павел / 28 лет

Инженер отдела интеграции

Меня интересует направление DevOps и облаков. Поэтому когда искал, как углубить знания, подкупили хорошие отзывы о REBRAIN, а окончательно убедило в выборе предложение компании пройти обучение. Сомнений не было.
Я доволен курсом, с трудом могу назвать хоть что-то, что мне не понравилось. Разве что некоторые примеры yaml файлов были с ошибкой, из-за чего не запускались в том виде, в котором была предоставлены, но ничего такого, что было бы сложно исправить. В остальном больше ничего не приходит на ум.
Особенно ценно в курсе:
1. Много полезных ссылок.
2. Полезный видеоматериал.
3. Хорошие практические задания.
Рекомендую всем администраторам Linux со стремлением развиваться в DevOps и облака.

Получите
консультацию

или пройдите вступительный тест

наши программы проходят
сотрудники из следующих компаний:

что ждёт
в конце?

certificat

получаете сертификат

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

предоставляем hard skills card

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

Hard Skills Card — ваша техническая карточка специалиста

hardskills
LPIC-1

У вас будут все необходимые знания и навыки, что бы сдать экзамены и получить сертификат Linux Professional Institute LPIC-1

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

linux icon

  • John doe
  • Системный администратор Linux
  • от 80 000 rub
  • технологический стек:

    • nginx, PostgreSQL, Docker, Prometheus, Grafana, Graylog.

    навыки:

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

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

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

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

    Senior DevOps engineer,
    DevOps Team Lead Fevlake,
    5 лет в DevOps-практиках,
    спикер DevOps by REBRAIN

    Опыт работы
    c devops:
    более 5 лет
    Николай Хватов

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

    Senior DevOps engineer,
    автор обучающих материалов Linux
    и Highload by REBRAIN

    Опыт работы
    c devops:
    более 8 лет
    fevlake

    команда инженеров
    fevlake

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

    практикум

    LINUX

    by rebrain

    Стоимость:
    4.500 р/мес5.000р

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

    Стоимость: 50.000 р

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

    Lifetime лицензия

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

    Money back 14 дней

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

    Доступна рассрочка на 10 месяцев

    tinkoff icon
    alfa bank icon

    быстрый старт

    При одновременной покупке практикумов Linux.Basic + Linux.Advanced общая стоимость – 75 000 руб. Цена действует только для физ.лиц

    basic + advanced linux

    Lifetime лицензия

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

    Money back 14 дней

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

    быстрый старт

    При одновременной покупке практикумов Linux.Basic + Linux.Advanced общая стоимость – 75 000 руб. Цена действует только для физ.лиц

    basic + advanced linux

    faq

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

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

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

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

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

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

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

    Rebrain

    Мы разработали инновационную модель онлайн-практикумов для
    IT-специалистов.

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

    Fevlake

    Международное агентство Devops-практик. Занимаемся
    проектированием и обслуживанием
    IT-инфраструктур с 2012 года.

    Наши клиенты:
    IMPROVE MEDIA, КупиКупон,
    CRYPTO EXCHANGE, NEWS360 и др.

    Файлы куки

    При использовании данного сайта, вы подтверждаете свое согласие на использование файлов cookie и других похожих технологий в соответствии с настоящим Уведомлением.