практикум

by rebrain

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

90% практики

Онлайн-практикум для знакомства и начала
работы с AWS (Amazon Web Services)

60+ заданий

Выполните все задания – освойте азы работы с облачными сервисами и станьте облачным инженером! Научитесь внедрять и поддерживать сервисы AWS, чтобы сэкономить затраты и увеличить гибкость инфраструктуры

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

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

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

200+ тысяч рублей

составляет зарплата DevOps-инженера с навыками работы с AWS

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

$270
миллиардов

превысили расходы на публичные облачные
сервисы за 2020 год

*по данным
Gartner

24,1%

выручки облачного рынка
без учета SaaS в 2020 году
пришлось на AWS, которая
опережает Microsoft и Google

*по данным
IDC

Gartner называет AWS лидером 2021 года по облачной инфраструктуре и платформенным сервисам. AWS уверенно сохраняет за собой данную позицию на протяжении многих лет

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

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

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

start here

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

01

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

02

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

03

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

04

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

05

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

06

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

07

почему
rebrain?

Эффектив-ность

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

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

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

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

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

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

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

более 60 задач

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

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

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

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

решите реальную задачу в рамках
облачной инфраструктуры Amazon

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

с которыми сталкиваются DevOps-инженеры, архитекторы решений, системные инженеры в AWS

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

DevOps-инженеры

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

системные инженеры

архитекторы IT-инфраструктуры

архитекторы решений

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

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

  • Приветствие. Чтo такое AWS?
  • Чем дышит AWS?
  • Подготовка к работе с AWS
  • Инструменты для работы с AWS
  • Техническая поддержка AWS
  • Основы биллинга
  • Тегирование

  • Основы
  • Пользователи
  • Политики
  • Группы
  • Роли

  • Вступление
  • Типы инстансов
  • Инстансы с балансом ресурсов (T)
  • Варианты покупки
  • Ресурсы для ознакомления (Free Tier)
  • Сетевые интерфейсы
  • Хранилища
  • Instance Store
  • EBS
  • EBS снимки (Snapshot)
  • Образ (AMI)
  • Правила доступа
  • Доступ SSH
  • Доступ через консоль (без предоставления SSH)

  • Обзор
  • EIP
  • Подсети (Subnets)
  • DHCP, DNS
  • Маршрутизатор (IGW and Egress Only GW)
  • Трансляция адресов (NAT)
  • Маршрутизация (Route tables)
  • Правила доступа для подсетей (NACL)
  • Security Groups
  • Peering
  • VPN
  • Стратегии организации доступа в VPC (Bastion, Client VPN, OpenVPN GW, etc)

  • Введение
  • Журналы (Logs)
  • Метрики (Metrics)
  • Будильники (Alerts)
  • События (Events)
  • Витрины (Dashboards)
  • Config
  • CloudTrail

  • Идентификатор (ID)
  • Жизненный цикл
  • Мета информация
  • Группирование
  • Сценарии на старте (User Data)
  • AMI
  • Работа с AWS CLI
  • IAM EC2 Profile
  • EIP EC2
  • Spot Instances
  • Savings Plans, Reserved Instances
  • Действия с EC2

  • Введение
  • DNS
  • Политика маршрутизации (Routing policy)
  • Регистрация доменов
  • Hosted zones. Public
  • Hosted zones. Private
  • Типы записей
  • Health checks

  • Введение
  • Сертификаты

  • Введение
  • Application LB
  • Classic LB
  • Network LB
  • Gateway LB
  • Таблица сравнения LBs

  • Введение
  • Жизненный цикл
  • Шаблоны
  • Параметры ASG
  • Load Balancing

  • Введение
  • Версионирование
  • Смотреть можно, менять нельзя (WORM-режим)
  • Классы хранения
  • Glacier / Deep Archive
  • Жизненный цикл объектов и события
  • Правила доступа
  • Репликация, Инвентаризация
  • Финальное задание

Примеры заданий
из практикума:

Подготовка к работе с AWS

Здравствуй! Сегодня мы будем создавать AWS Account (далее аккаунт).

Аккаунт — это выделенное пространство для всех ресурсов, которые вы создаете в AWS, и вам предоставляются доступ к управлению ресурсами и информация о стоимости (billing) этих ресурсов. Каждый аккаунт имеет уникальный 12-ти значный цифровой номер — идентификатор, который называется Account ID.

Создание аккаунта не тарифицируется, но всё же обходится в 1$, который будет списан в качестве проверки вашей банковской карты на этапе создания. Это единоразовый платеж.

В дальнейшем, при смене карты, 1$ будет только блокироваться на время проверки новой карты и после завершения вернется вам на карту.

Заплатив 1$ при создании, вы получаете сразу довольно много. А именно, специальный комплект ресурсов на 12 месяцев, именуемый Free Tier, который мы подробно рассмотрим позже. Поверьте, этот комплект ресурсов стоит гораздо больше, чем 1$.

Создаем аккаунт:

Для создания аккаунта нам потребуются:

  • Веб-браузер. Рекомендую Mozilla Firefox, Google Chrome, MS Edge, Apple Safari.
  • Действующая банковская карта с балансом минимум 1$.

Переходите по ссылке https://portal.aws.amazon.com/billing/signup#/start и просто следуйте за мной в следующем видео-уроке. Будет здорово! Поехали.

Screencast 1: Создание Учетной записи (Account)

Для доступа к ресурсами AWS используются:

  • AWS Management Console: для управления с помощью любого современного браузера. Мы знакомились с веб-консолью в предыдущем задании.
  • Programmatic: для различных программных инструментов, AWS API, CLI, SDK и другие.

Важный момент для нас — это знать свой Account ID. Запишите его в блокнот, он нам понадобится и не раз.

Если потребуется, Account ID всегда можно найти в консоли в правом верхнем углу выпадающее меню под именем аккаунта.

При регистрации мы указывали свой Email и пароль. С помощью браузера мы теперь всегда сможем зайти в наш аккаунт по ссылке https://aws.amazon.com/ru/console/

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

  • войти как Root user;
  • войти как IAM user.

Мы обязательно подробно разберемся с IAM user в следующем модуле, a в этой задаче мы работаем как Root user.

Выбирайте Root user, вводите Email, который использовали при создании аккаунта, немного проверок (Captcha), далее пароль. Перед нами консоль управления нашим аккаунтом. Но прежде, чем начнем что-то создавать, пару слов о деньгах.

Уровень бесплатного пользования (Free Tier)

AWS предоставляет для новых Accounts специальные предложения для ознакомления: Free Tier или Уровень бесплатного пользования AWS. Следует понимать, какие типы предложений существуют:

  • Всегда бесплатно: бессрочный бесплатный доступ для всех клиентов AWS. С одним таким сервисом мы познакомимся в Модуле 8 — Certificate Manager. Да, AWS выдаёт SSL сертификаты бесплатно! Но не просто так:)
  • Пробный доступ: бесплатный пробный период какого-то сервиса. Обычно короткий и действует с момента активации сервиса. Как правило, это новый сервис AWS, который проходит этап тестирования или предоставляется для краткого ознакомления единожды.
  • 12 месяцев бесплатно: 12 месяцев с начала создания аккаунта. Этот тип предложения мы рассмотрим подробнее.

Важно понимать:

  • Есть момент создания Account, с которого начинается отсчёт 12-ти месяцев.
  • По окончании 12-и месяцев с момента создания, предложения такого типа более не доступны для текущего Accoun
  • в течение этого 12-и месячного периода доступны для ознакомления и использования ТОЛЬКО определенные типы ресурсов и только в тех рамках, что описаны в предложении.

Полный список ресурсов уровня бесплатного пользования AWS

С последним пунктом следует разобраться подробнее на примерах. Один из ресурсов такого типа предложения — использование виртуальных машин в течение 750 часов в месяц. При всей кажущейся щедрости этого предложения, следует внимательно прочитать детали!

Одна из важнейших мыслей при работе с AWS должна быть эта: ВСЕГДА держите руку на пульсе вашего бюджета.

Итак, в чём особенность такого предложения:

  • Суммарно 750 часов в месяц для бесплатного использования виртуальных машин ТОЛЬКО в конфигурации t2.micro с Linux, RHEL, SLES, Windows. Еще чуть более подробно: если запустить виртуальную машину типа t2.micro (1 vCPU, 1GB) и оставить её работать непрерывно в течение месяца (24 часа * 30 дней = 720 часов), то такое использование будет бесплатным в этот период. Однако, если запустить две такие виртуальные машины, то суммарно они проработают: 720 часов в месяц * 2 виртуальные машины = 1440 часов. Итого AWS нам выставит счёт на оплату тех часов, которые не входят в 750 часов: 1440 часов по факту — 750 часов бесплатного использования = 690 часов по тарифу, согласно стоимости такого типа виртуальной машины.
  • Мы подробнейшим образом разберёмся, что такое t2.micro в модуле 3, который посвящен этому, но, забегая вперёд, поясним, что это 1 vCPU, 1GB памяти и 8GB корневого диска. Но и это ещё не всё. Виртуальные машины с типом t2.micro имеют так называемую базовую загрузку на виртуальный ЦПУ, которая для t2.micro равна 10%. Это означает, что только 10% в среднем от 1-го vCPU вам будет предоставлено в рамках этого предложения.

Не всё так просто, но нам пока этого достаточно. Подробно разбираемся в модуле 3.

Второй пример, однако, показывает такой тип предложения с другой стороны. Предлагается бесплатно использовать 5 ГБ стандартного хранилища Amazon S3 (подробно мы с ним знакомимся в модуле 11). Это действительно означает, что в течение 12-ти месяцев вы можете хранить до 5 ГБ бесплатно.

Опять же есть нюансы: это предложение касается не только объема 5 ГБ, но в предложении описан уровень бесплатного использования КОЛИЧЕСТВА запросов типа Get = 20 000 и запросов типа Put = 2000. При превышении этих пороговых значений будет начисляться плата. Например, записываем один файл размером 4 ГБ 1-го января и для нас его хранение будет действительно бесплатным все 12-ть месяцев. Если мы попытаемся выполнить множество операций записи в этот файл, но не превысим порог в 2000 раз, то также это будет для нас бесплатно. А вот с операциями Get совсем не так просто. В рамках 20 000 операций Get — это бесплатно, НО, AWS тарифицирует ВЕСЬ ИСХОДЯЩИЙ трафик :)

Для ознакомления и понимания работы AWS, использовать Free Tier можно и нужно.

Но будьте внимательны и читайте детали предложений!

Работаем с аккаунтом как Root user

Root user — это специальный режим доступа, который позволяет выполнить все возможные действия для текущего аккаунта.

Root user не следует использовать в повседневной работе! Этот пользователь нужен для первичной настройки аккаунта и создания администраторов, делегирования прав, регистрации платежных карт и других важнейших действий в аккаунте. Никто другой не может выполнять действия, которые доступны Root user.

MFA для Root user

Отсюда следует и особое отношение к безопасности. Первое, что мы сделаем прямо сейчас, защитим нашего Root user специальным механизмом, который называется Multi-Factor Authentication (MFA). Это рекомендуемый уровень для такого важного типа доступа.

Всегда включайте MFA для Root user!

Подробнее о том, что такое AWS MFA, можно почитать здесь: https://aws.amazon.com/ru/iam/features/mfa/ Кратко. Для успешной аутентификации кроме имени и пароля потребуется ввести специальный код, который генерируется неким устройством (device). Это устройство синхронизировано во времени (имеет точное время).

Для работы с MFA можно использовать:

  • Virtual MFA Device: это подразумевает использование специальных, поддерживающих open TOTP standard приложений на смартфоне. Этот вариант не требует дополнительных затрат.
    Список приложений: Authy, Duo Mobile, LastPass Authenticator, Microsoft Authenticator, Google Authenticator
    Рекомендуем для нашего курса использовать Google Authenticator, так мы будем говорить об одном и том же.
  • Hardware MFA Device: различного рода устройства в виде брелоков, которые предоставляют дополнительные функции, но они приобретаются отдельно. AWS не взимает плату за их использование.

Мы будем использовать Virtual MFA Device. Для этого:

  • установите приложение Google Authenticator на ваш смартфон;
  • войдите в консоль аккаунта и в правом верхнем углу нажмите на строку с именем аккаунта (если имя не установили, то вместо имени будет Account ID) и в выпадающем списке выбирайте пункт My Security Credentials

    Картинка примера 1
  • среди закладок раскройте Multi-Factor Authentication (MFA);
  • нажимайте кнопку Activate MFA;
  • в списке выбирайте Virtual MFA device -> Continue;
  • в окошке нажимаем Show QR code и запускаем приложение Google Authenticator на смартфоне;
  • в приложении в правом нижнем углу нажимаем на + и выбираем пункт Сканировать QR-код;
  • сканируем QR-код и после добавления ключа в список приложения, видим наш MFA код — шесть цифр. Вводим их в поле MFA code 1;
  • ждем смены кодов и новые 6-ть цифр вводим в поле MFA code 2;
  • нажимаем кнопку Assign MFA.

Здесь находится документация для самостоятельного углубленного изучения.

Virtual MFA Device можно заменить, удалить, синхронизировать. Всё это можно выполнить при необходимости, пройдя тем же путем, что мы создавали Virtual MFA Device.

Кстати, частый вопрос, а что делать если потерялся смартфон, утратили доступ к Virtual MFA, или он не работает?

  • Для входа используем Email и пароль, которые использовали при создании аккаунта.
  • На странице Amazon Web Services Sign In With Authentication Device выбираем Having problems with your authentication device? Click here.
  • На странице Sign In Using Alternative Factors of Authentication выбираем Sign in using alternative factors.
  • Далее выбирайте Resend the email (отправить письмо на Email) и следуйте рекомендациям по восстановлению доступа.
  • После входа в Account, замените прежний Virtual MFA Device на новый. Подробная документация

У нас всё готово для работы с аккаунтом как Root user с MFA.

Входим в аккаунт как Root user с использованием MFA. Теперь для входа с нас потребуют не только Email и пароль, но и еще одно поле появится в запросе процесса аутентификации — код, который мы вводим, считывая его в приложении Google Authenticator.

Настройка аккаунта

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

AWS Config

Это сервис, который непрерывно следит за ресурсами и их изменениями. Этот сервис позволит нам понимать кто, когда и как изменял ресурс (создавал, удалял, менял конфигурацию). Это позволяет выполнять аудит с помощью просмотра истории событий, используя специальные запросы (Advanced Queries), применяя правила.

Config первый платный сервис, с которым мы сталкиваемся. Его стоимость зависит от региона, количества записанных событий, количества примененных правил.

AWS Config — это региональный сервис. Это означает, что его нужно включать в тех регионах, с которыми планируется работать.

Стоимость AWS Config

Документация по AWS Config

AWS CloudTrail

Это сервис, который, как и AWS Config, непрерывно следит за ресурсами и их изменениями. Но, в отличии от Config, этот сервис записывает историю аккаунта в действиях, которые производились как с консоли, так и через API. Есть два типа событий, которые CloudTrail может сохранять:

  • События управления ресурсами.
  • События работы с данными.

Например, к первому типу относятся события создания, удаления ресурса, а ко второму типу — запись файла или его изменение.

CloudTrail бесплатен при регистрации только событий управления за последние 90 дней. Это начальный уровень использования. Далее тарификация производится при включении дополнительных функций.

AWS Cloudtrail — это региональный сервис. Это означает, что его нужно включать в тех регионах, с которыми планируется работать.

Стоимость AWS CloudTrail

Документация по AWS CloudTrail

Политика использования паролей

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

  • Войдите в консоль управления AWS.
  • Перейдите в сервис IAM.
  • Слева выбирайте "Account settings".
  • Нажимайте кнопку "Change password policy".
  • Установите политику, согласно вашему требованию.
Делегируем права на просмотр затрат (Billing)

Мы уже говорили о том, что работать ежедневно под Root user не рекомендуется. И мы постепенно приближаемся к этому моменту, когда всё будет готово для того, чтобы отказаться от использования Root user. По умолчанию доступ к информации о затратах (Billing) доступен только Root user, но мы можем передать (делегировать) это право другим пользователям:

  • Войдите в консоль управления AWS.
  • В правом верхнем углу щелкаем на имени аккаунта и в выпадающем списке выбираем "My Account".
  • Пролистайте вниз эту большую страницу до пункта "IAM User and Role Access to Billing Information".
  • Правее от названия пункта есть ссылка "Edit". Нажимайте.
  • Установите флажок для "Activate IAM Access".
  • Нажмите кнопку "Update".
Включаем уведомления о порогах использования Free Tier

Бесплатные ресурсы заканчиваются довольно быстро, потому что они не так уж и велики, но вполне достаточны для ознакомления. Чтобы быть в курсе того, что мы подобрались к границам бесплатного использования ресурсов, включим оповещения об этом:

  • Войдите в консоль управления AWS.
  • В правом верхнем углу щелкаем на имени аккаунта и в выпадающем списке выбираем "My Account"
  • Слева выбирайте "Billing preferences".
  • Найдите пункт "Cost Management Preferences" и нажмите на него, чтобы раскрыть.
  • Установите флажок для "Receive Free Tier Usage Alerts".
  • Если требуется указать Email отличный от того, что мы указали при регистрации, введите его в "Email Address".
  • Нажмите кнопку "Save preferences".
Настройка ссылки на AWS Managed Console

По умолчанию ссылка на консоль управления выглядит в общем виде так: https://console.aws.amazon.com/console/home и AWS перенаправит вас на форму запроса Email и пароля. И по Email уже будет вычисляться, в какой аккаунт вы пытаетесь войти.

Ссылка на консоль управления может иметь другой формат, с меньшим количеством перенаправлений: https://<ACCOUNT_ID>.signin.aws.amazon.com/console/

Запоминать 12-ти значный числовой код не просто. И AWS предлагает установить специальное имя, псевдоним (Alias), для вашего аккаунта, которое можно использовать как часть ссылки:
https://<ACCOUNT_ALIAS>.signin.aws.amazon.com/console/ Установить удобное для запоминания имя на консоль управления можно так:

  • Войдите в консоль управления AWS.
  • Переходите в сервис IAM.
  • По умолчанию будет выбран пункт "IAM dashboard".
  • В правом фрейме (окошке, что отделено вертикалью от меню) под пунктом "Sign-in URL for IAM users in this account" будет указана текущая ссылка на консоль управления.
  • Нажмите напротив ссылки на "Edit".
  • Введите новое значение и нажмите "Save".

После установки псевдонима (alias) прежняя ссылка с Account_ID также будет продолжать работать. Чтобы удалить псевдоним, нажмите вместо "Edit" на "Delete alias", и ссылка вернется к прежнему значению с Account ID.

Совсем немного IAM

Про сервис Identity and Access Management мы будем очень подробно говорить в модуле 2. Но сейчас он нам нужен для подготовки нашего аккаунта для прохождения практикума. Чтобы создать пользователя, нам потребуется выполнить такие шаги:

  • Войдите в консоль управления AWS.
  • Переходим в сервис IAM.
  • Создадим группу администраторов:
    • Слева выбираем User groups и нажимаем кнопку "Create group".
    • Вводим имя: "Admins".
    • В пункте "Attach permissions policies" найдите политику с именем "ReadOnlyAccess" и отметьте ее флажком.
    • Нажмите "Create group".
  • Создадим пользователя:
    • Слева выбираем "Users" и нажимаем "Add user".
    • User name: admin .
    • "Access type" выбираем оба варианта и оставляем предложенные настройки по умолчанию.
    • Нажимаем "Next: Permissions".
    • Выбираем из списка нашу ранее созданную группу "Admins".
    • Нажимаем "Next: Tags".
    • Нажимаем "Next: Review".
    • Нажимаем "Create user".
    • Внимание! Нам покажут важный экран, где мы можем скачать подготовленный файл с ключами доступа, именем и паролем для входа в консоль управления. Обязательно скачайте и сохраните в безопасном месте, этот важный файл. Его также можно отправить по почте при необходимости.
    • Посмотреть ключи доступа больше не будет возможности в консоли управления AWS, только заменить!
    • Нажимайте "Close".

Для закрепления материала — пользователь может иметь возможность пройти аутентификацию, указав имя и пароль, и, возможно, MFA-код. Такой метод работает для консоли управления.

А также, тот же самый пользователь может использовать свои уникальные ключи доступа при работе через AWS CLI, SDK и другими инструментами.

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

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

  • Идентификатор ключа, его имя: access key ID. Немного похоже на имя пользователя в системе username/password.
  • Значение ключа: access secret key. Эта часть похожа на пароль.

Про ключи доступа мы подробно поговорим еще в модулях про IAM и в задачах про AWS CLI. На текущий момент следует запомнить и выполнять для обеспечения безопасности AWS Account:

  • ключи доступа никогда не следует передавать в публичный доступ;
  • ключи доступа однозначно идентифицируют конкретного пользователя в конкретном Account и всегда связаны с тем набором прав, которые выданы этому пользователю;
  • ключи доступа не нужно вписывать в код вашего ПО и нельзя допускать хранения ключей в Git репозиториях;
  • ключи должны проходить процедуру периодического обновления (rotation).
Создание роли для команды REBRAIN

И последнее, что нам потребуется, — это создать некую сущность — роль, которая требуется команде кураторов и преподавателей для подготовки заданий и их проверок. Про роли мы очень подробно поговорим в модуле 2. Пока нам будет достаточно того, что роль (IAM Role) — это не пользователь и не группа. Это некая именованная (то есть имеет имя) сущность, у которой есть права, и эти права описаны политиками. Также у роли есть специальные способности создавать доверительные отношения между разными аккаунтами. Именно эта способность нам и потребуется.

  • Создайте IAM Role для работы команды преподавателей с вашим Аккаунтом:
    • Переходим в сервис "Identity and Access management (IAM)".
    • Выбирайте слева в столбике пункт "Roles" и нажимайте синюю кнопку сверху "Create role".
    • Выбирайте type of trusted entity => "Another AWS account".
    • Account ID: 644874760385.
    • Options: "Require External ID и Require MFA" оставьте по умолчанию, не выбранными!
    • Next: "Permissions"
    • Attach permissions policies: найдите в списке "AdministratorAccess" и отметьте галочкой только её.
    • Next: "Tags".
    • Next: "Review"
    • Role name: rebrain-control-role
    • "Create role"

Всё. Отличная работа!

И прежде, чем мы завершим наше задание, познакомимся с еще одним важнейшим персонажем, который будет с нами практически всегда — ARN.

ARN

AWS предоставляет сотни сервисов и каждый из них может создавать сотни и тысячи ресурсов. Чтобы однозначно определить такой ресурс в этом множестве ресурсов, AWS используется специальный уникальный идентификатор для каждого ресурса, который называется Amazon Resource Number или сокращенно ARN. ARN имеет строгий формат и нам нужно уметь его читать и составлять. Составлять нужно уметь для того, чтобы не искать нужный нам ARN, считывая его с ресурса, а составить его по строгому формату.

Давайте разберём формат:

arn:partition:service:region:account-id:resource-id
arn:partition:service:region:account-id:resource-type/resource-id
arn:partition:service:region:account-id:resource-type:resource-id

ARN имеет всегда вначале своё же сокращение — arn. И далее множество полей, разделенные двоеточием:

  • partition: это группа AWS регионов. Мы уже разбирали, что такое регионы, и здесь это поле может иметь одно из трёх значений:
    • aws — AWS регионы.
    • aws-cn — регионы Китая.
    • aws-us-gov — специальные регионы AWS для государственных нужд.
  • service: указывает на AWS продукт, сервис. Например: s3, ec2.
  • region: код региона. Например: eu-west-1, us-east-2.
  • account-id: 12-и значный идентификатор аккаунта, Account ID, который является владельцем ресурса.
  • resource-id: идентификатор ресурса. Причем здесь может быть как имя, так и идентификатор ресурса или путь ресурса. Например: user/Peter, instance/i-4034567898abcdeff.

Путь в ARN может содержать специальный символ звёздочка — (), который означает буквально — все.

Например:

arn:aws:iam::223344556677:user/ — означает все пользователи.
arn:aws:iam::223344556677:group/* — означает все группы.

Символ звёздочка не может применяться для обозначения части типа ресурсов:

arn:aws:iam::223344556677:g* — это ошибка!
arn:aws:iam::223344556677:group/* — верное использование.

Обратите внимание на тот факт, что НЕКОТОРЫЕ поля в ARN могут быть пустыми:

arn:aws:iam:::user/Peter — обратите внимание на то, что после имени сервиса (iam) и до имени ресурса у нас здесь не указаны (пропущены):

  • region
  • account Id

Это означает, что регион не применим для данного типа ресурса. Мы не используем для обозначения всех регионов звёздочку, просто оставляем поле региона пустым. И это не потому, что мы столкнулись с каким-то исключением, а потому, что AWS имеет как региональные сервисы, и тогда мы указываем регион, чтобы однозначно понять расположение сервиса, к которому этот ARN относится, так и глобальные сервисы, которые не привязаны к регионам. Если поле account Id пропущено, оставлено пустым, то это означает наш, текущий Account ID.

ARN мы будем встречать часто, по мере знакомства с AWS.

Создать аккаунт.
Настроить доступ для Root user с использованием Virtual Device MFA.
Настроить политику использования паролей:
  • Enforce minimum password length: 16
  • Require at least one uppercase letter from Latin alphabet (A-Z): да
  • Require at least one lowercase letter from Latin alphabet (a-z): да
  • Require at least one number: да
  • Require at least one non-alphanumeric character (! @ # $ % ^ & * ( ) _ + - = [ ] { } | ') : да
    • Expire passwords in 90 days
  • Password expiration requires administrator reset: НЕТ
  • Allow users to change their own password: да
  • Prevent password reuse: да
    • Remember 5 passwords
Включить возможность доступа к Billing для пользователей
Настроить псевдоним (alias) для ссылки доступа к консоли (Account Alias).
Создать группу с именем Admins с политикой SystemAdministrator.
Создать пользователя с именем admin с возможностью доступа как через консоль так и через API, и включить его в группу Admins. Сохраните файл с информацией о доступе для этого пользователя.
Создать роль:
  • Тип: Another AWS account
  • Account ID: 644874760385
  • Политика: ReadOnlyAccess
  • Имя: rebrain-control-role
Если всё это создано согласно списка, то:
  • Нажимайте кнопку Создать окружение
  • Войдите на созданную виртуальную машину по SSH с указанными учетными данными
  • Создайте файл с именем ~/aws-account-id и скопируйте в него ваш Account ID. Это 12-ть цифр и ничего лишнего. Сохраните файл
  • Проверьте его содержимое: cat ~/aws-account-id. Должен напечататься только 12-ти значный цифровой Account ID
  • Нажмите кнопку Начать проверку

Мы знакомы с VPC и знаем, что внутри подсетей используются приватные IP-адреса.

Довольно частая задача на практике состоит в соединении двух VPC друг с другом.

Такая сетевая связь двух VPC в AWS называется Peering.

  • VPC Peering может быть создан между VPC в одном и том же регионе, в различных регионах, а также в различных регионах разных аккаунтов.
  • Трафик VPC Peering никогда не покидает сетей ЦОД AWS, никогда не выходит в Интернет и не проходит через Интернет.

Документация AWS предлагает вот такую схему для понимания VPC Peering:

Картинка примера 2

Обратите внимание, что VPC A и VPC B имеют разные CIDR!

Ключевое требование для создания межсетевого взаимодействия между VPC (Peering) — первичные CIDR VPC не должны перекрываться!

То есть, если бы VPC A имела первичный CIDR = 172.31.0.0/16, а VPC B имела бы первичный CIDR = 172.31.0.0/16, то создание VPC Peering между этими VPC было бы невозможно.

Когда у нас VPC с разными первичными CIDR, мы имеем возможность создать между ними сетевое соединение — Peering. Это соединение требует действия с различными объектами.

Самое первое действие — создание самого соединения (Peering).

VPC, которая запрашивает создание VPC Peering, называется Инициатором (Requester). VPC, связь с которой запрашивается, называется Приёмником (Accepter).

При создании VPC Peering мы создаем запрос от VPC Requester к VPC Accepter. Но при этом связь не будет установлена до тех пор, пока VPC Accepter явно не даст своё согласие на такое соединение. Такой процесс называется Одобрением (Accept).

Давайте рассмотрим жизненный цикл такого запроса:

Картинка примера 3
  • Initiating-request — именно в этой фазе проверяется фактическая возможность создания такого соединения. Проверяется перекрытие первичных VPC CIDR. Эта фаза может перейти в одну из следующих фаз — отказ (failed) или ожидание (pending acceptance). Фаза failed является завершающей и запрос будет сброшен.
  • pending acceptance — ожидание одобрения. Эта фаза может принять следующие состояния:
    • expired — если запрос не будет принят в течение 7 дней, такой запрос будет уничтожен.
    • rejected — на запрос Инициатора вторая сторона может ответить явным отказом, и тогда такой запрос так же будет уничтожен.
    • deleted — пока запрос не был принят, в течение 7-ми дней, инициатор запроса может по своей инициативе удалить свой запрос, и такой запрос будет уничтожен.
  • provisioning — предоставление связи. Это возможно, если запрошенная сторона явно приняла запрос на создание, пока не закончился период ожидания — 7 дней.
  • active — конечное состояние установления связи.

Итак, если VPC Peering имеет состояние Active, это означает, что мы можем использовать созданное соединение.

VPC Peering — это компонент VPC и у него есть уникальный идентификатор, который начинается с pcx-.

Важно понимать, что требование иметь у VPC неперекрывающиеся первичные CIDR, требуется для того, чтобы мы могли описать правила маршрутизации между нашими подсетями.

Маршрутизация трафика описывается, как мы знаем, в таблицах маршрутизации. Таблицы маршрутизации связаны с подсетями. Дальнейшие наши действия будут связаны с описанием правил маршрутизации между подсетями наших VPC.

Screencast: VPC Peering

Сценарий связи VPC полным CIDR

Давайте начнём с просто сценария — две VPC связываем вместе полными первичными CIDR:

Картинка примера 4

Для подсети в VPC A существует таблица маршрутизация, в которой есть как минимум одно правило маршрутизации:

Destination Target
10.0.0.0/16 local

И мы добавляем новый маршрут:

Destination Target
172.31.0.0/16 pcx-11111

Здесь pcx-123456789xxxx — это идентификатор созданного VPC Peering между VPC A и VPC B.

Но этого недостаточно. Для подсети в VPC B существует также своя таблица маршрутизации, в которой есть какие-то свои маршруты, но мы должны добавить еще один маршрут:

Destination Target
10.0.0.0/16 pcx-11111

Здесь pcx-123456789xxxx тот же самый идентификатор созданного VPC Peering между VPC A и VPC B.

Если бы первичные CIDR у VPC были бы одинаковыми, мы не смогли бы прописать правила маршрутизации.

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

Второй момент — это Security groups. Если мы хотим разрешить сетевые соединения между двумя инстансами в наших VPC, связанных VPC Peering, мы должны добавить в SG правила, разрешающие такие соединения.

Мы можем добавлять правила с указанием CIDR подсетей или же с указанием идентификаторов SG в наших VPC.

Если мы хотим использовать идентификаторы SG из другой VPC, мы просто указываем этот SG ID. Однако, если мы создали VPC Peering между VPC в разных аккаунтах, то SG ID должен будет иметь другой формат: account-ID/sg-ID.

SG ID можно использовать в правилах SG только при условии, что VPC Peering имеет статус Active.

На этом настройка завершилась, и мы связали объекты в разных VPC, используя только приватные адреса.

Стоимость VPC Peering равна нулю, но стоимость трафика имеет особенности:

  • если обе VPC находятся в одном регионе, то стоимость трафика равно нулю;
  • если VPC находятся в разных регионах, то трафик будет тарифицироваться по так называемому Inter-Region тарифу.
Сценарий связи конкретных подсетей или адресов

По сути это частный случай предыдущего варианта. Изменения, которые нам нужно сделать для такого сценария, минимальны. А именно, мы должны скорректировать маршруты не полные VPC CIDR, а только на требуемые адреса подсетей или даже адреса инстансов или других объектов.

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

В таблицу маршрутизации подсети из VPC A мы добавляем маршрут:

Destination: 172.31.0.0/24 <-- это CIDR подсети из VPC B
Target: pcx-123456789xxxx

Здесь pcx-123456789xxxx — это идентификатор созданного VPC Peering между VPC A и VPC B.

В таблицу маршрутизации подсети VPC B мы добавляем маршрут:

  • Destination: 10.0.0.0/24 <-- это CIDR подсети из VPC A
  • Target: pcx-123456789xxxx

Здесь pcx-123456789xxxx — это идентификатор созданного VPC Peering между VPC A и VPC B.

Разница между первым сценарием и вторым только в том, какие CIDR мы используем. В первом сценарии мы используем CIDR всей VPC, а во втором сценарии мы используем CIDR подсетей VPC. Так же мы можем использовать кроме CIDR подсетей конкретные адреса объектов, например инстансов. В этом случае мы добавляем адрес инстанса:

Destination: 172.31.0.10/32

И еще пара деталей:

  • Если VPC имеют более одного CIDR, то маршруты мы должны прописывать для каждого CIDR, который должен участвовать в соединениях.
  • Если нам нужно использовать IPv6, мы должны прописывать маршруты IPv6.
VPC Peering множеств VPC

VPC Peering — это связь между двумя VPC.

VPC Peering не поддерживает транзит трафика!

Это означает, что создав схему:

VPC A <- peering -> VPC B <- peering -> VPC C

мы не сможем создать соединение между объектами VPC A и VPC C. Соединения возможны в этой схеме только между объектами VPC A и VPC B, а также между VPC B и VPC C. Но не между VPC A и VPC C!

Однако, вот такая схема вполне рабочая:

<- peering -> VPC B

/

VPC A
\
<- peering -> VPC C

Здесь требуется создать два VPC Peering и следовательно, маршруты должны будут ссылаться соответственно им.

Создадим такие маршруты. Вводные данные:

  • VPC A: 10.1.0.0/16
  • VPC B: 172.17.0.0/16
  • VPC C: 172.16.0/16
  • VPC Peering: VPC A <--> VPC B: pcx-11111
  • VPC Peering: VPC A <--> VPC C: pcx-22222

Таблицы будут иметь такие маршруты:

  • VPC A:

    Destination Target
    172.17.0.0/16 pcx-11111
    172.16.0.0/16 pcx-22222
  • VPC B:

    Destination Target
    10.1.0.0/16 pcx-11111
  • VPC C:

    Destination Target
    10.1.0.0/16 pcx-22222

Вот такая схема тоже рабочая:

VPC A <--> VPC B
\ /

VPC C

Здесь требуется создать три VPC Peering, и следовательно, маршруты должны будут ссылаться соответственно им.

Создадим такие маршруты. Вводные данные:

  • VPC A: 10.1.0.0/16
  • VPC B: 172.17.0.0/16
  • VPC C: 172.16.0/16
  • VPC Peering: VPC A <--> VPC B: pcx-11111
  • VPC Peering: VPC A <--> VPC C: pcx-22222
  • VPC Peering: VPC B <--> VPC C: pcx-33333

Таблицы будут иметь такие маршруты:

  • VPC A:

    Destination Target
    172.17.0.0/16 pcx-11111
    172.16.0.0/16 pcx-22222
  • VPC B:

    Destination Target
    10.1.0.0/16 pcx-11111
    172.16.0.0/16 pcx-33333
  • VPC C:

    Destination Target
    10.1.0.0/16 pcx-22222
    172.17.0.0/16 pcx-33333

Вот такие схемы также рабочие:

Картинка примера 5Картинка примера 6

Посмотрите на схемы, которые невозможны

Устаревшие SGs (Stale SGs)

Случается так, что создали VPC Peering, прописали SG, которые ссылаются на SG в той VPC, с которым был создан Peering. Позже VPC Peering стал не нужным и его удалили. В такой ситуации ссылки на SG в другой VPC уже недоступны, и теперь такие SG называются устаревшими (Stale).

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

  • Используя веб-консоль переходим в VPC.
  • Выбираем раздел слева Security groups.
  • В меню Actions выбираем "Manage stale rules".
  • Выбираем VPC, для которой выполняем чистку.
  • Выбираем "Edit" -> "Delete" на каждом правиле, что требует чистки.
  • Нажимаем "Preview changes" и, если всё хорошо, то "Save rules".

Создайте в регионе us-east-1 ресурсы:
VPC A:
  • Имя: vpc-a
  • CIDR: 172.16.0.0/16
  • CIDR: 10.10.0.0/16
  • Приватная подсеть без NAT GW
    • Имя: private1-subnet
    • CIDR: 10.10.0.0/24
  • Публичная подсеть
    • Имя: public1-subnet
    • CIDR: 172.16.0.0/24
VPC B:
  • Имя: vpc-b
  • CIDR: 172.17.0.0/16
  • CIDR: 10.11.0.0/16
  • Приватная подсеть без NAT GW
    • Имя: private1-subnet
    • CIDR: 10.11.0.0/24
  • Публичная подсеть
    • Имя: public1-subnet
    • CIDR: 172.17.0.0/24
Инстанс:
  • Имя: server-a1
  • VPC: vpc-a
  • Subnet: private1-subnet
  • Тип: t2.micro
  • OS: Amazon Linux 2
Инстанс:
  • Имя: server-b1
  • VPC: vpc-b
  • Subnet: public1-subnet
  • Тип: t2.micro
  • OS: Amazon Linux 2
VPC Peering
  • Имя: vpc-a-vpc-b

Добейтесь того, чтобы инстанс server-a1 и server-b1 могли выполнить:

  • ping в обе стороны: server-a1 может пингать server-b1 и наоборот;
  • server-a1 в этой схеме не имеет возможности выхода в интернет, потому что мы не создали NAT GW (по условию задачи). Создайте возможность выходить в Интернет для server-a1 используя SSH и созданный VPC Peering. Проверьте работу такого решения тем, что yum install nc с server-a1 выполнялся корректно. Не создавайте NAT GW!

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

VPC, EC2, IAM, S3, Route 53, CloudWatch, CloudTrail, Certificate Manager, Elastic Load Balancing, Billing, EBS, VPN, AMI, Auto Scaling, Elastic Ip, Elastic network interface, Trusted Advisor

После нашего практикума вы
научитесь работать с данными
инструментами, а также:

  • Создавать и настраивать аккаунт AWS
  • Разбираться в основных терминах, концепциях и нюансах работы с сервисами AWS
  • Понимать принцип работы облачных сервисов
  • Проектировать, поддерживать и мониторить облачную инфраструктуру
  • Строить комплексные cloud-native решения в облаке AWS

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

Познакомиться с основами работы облачной инфраструктуры на примере AWS

01

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

02

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

03

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

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 (одна штука) в команде разработки.

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

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

@berem

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

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

Илья / 28 лет

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

@ilbka

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

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

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

[email protected]

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

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

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

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

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

certificat

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

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

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

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

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

hardskills

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

incognito

  • John doe
  • devops-engineer + aws
  • 200.000 rub
  • технологический стек:

    • VPC, EC2, IAM, S3, Route 53, CloudWatch, CloudTrail, Certificate Manager, Elastic Load Balancing, Billing, EBS, VPN, AMI, Auto Scaling, Elastic Ip, Elastic network interface, Trusted Advisor

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

    Роман Шнырёв

    cloud & AI architect
    Роман Шнырёв

    Развитие новых технологических продуктов, оценка потенциала инновационных инфраструктурных решений в сегменте enterprise, применение лучших практик мировых лидеров в Cloud, Edge computing в том числе с AI

    Опыт работы
    в IT:
    20 лет
    Михаил политаев

    epam systems
    Михаил политаев

    Ведущий инженер по внедрению и поддержке ПО EPAM Systems

    Опыт работы
    в IT:
    более 6 лет
    Николай панченко

    rebrain
    Николай панченко

    Администратор безопасности, DevOps-практик, методист REBRAIN

    Опыт работы
    в IT:
    6 лет
    Максим пеньков

    Cloud & Network Services
    Максим пеньков

    Ведущий разработчик группы Cloud & Network Services Topcon Positioning Systems Inc.

    Опыт работы
    с AWS:
    3 года

    практикум

    by rebrain

    Стоимость:
    6.990 р/мес8.500 р.

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

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

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

    Lifetime лицензия

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

    Money back 14 дней

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

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

    tinkoff icon
    alfa bank icon

    Lifetime лицензия

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

    Money back 14 дней

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

    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 и других похожих технологий в соответствии с настоящим Уведомлением.