Сегодня мы с шефом поставили все точки над i по поводу моих целей на 2018 год. Цели у меня следующие:
- получить AWS Certified Developer Associate
- закрыть пробелы мониторинга, согласно Definition of Health
- имплементировать zero downtime deployment.

Самая интересная цель, пожалуй, третья.
Читатель, знакомый с такими методами, как Canary или Green/Blue deployment, решит, что это легко.
Инженер, проработавший с Kubernetes, решит, что это еще проще. (Kuber такое делает вообще из коробки)

Но мое положение немного отличается, так как в стеке у нас DC/OS и Marathon.

Поэтому мою задачу можно решить разными способами: от заменой Марафона Кубером до написания собственных велосипедов по Green/Blue.

Это, кстати, эталонный пример условной Вундервафли, о которой я так люблю писать, но раз уж у меня есть целых 9 месяцев, чтобы это сделать, я распишу весь процесс (от техники до менеджмента) гораздо позже. А пока в качестве условно сложного проекта я представлю вам задачу под названием “DEVOPS-74 DC/OS Tooling environment”, которая свалилась на мои плечи позавчера, и по которой я провожу исследование, что тот ученый сын маминой подруги. Уверен, вся история покроет две темы, запрошенные моими читателями раньше (https://t.me/manandthemachine/178)

Завтра распишу изначальную постановку задачу, и как я ее разжевывал. Stay tuned.

Для начала небольшой ликбез, о том как вообще устроено у нас все и как работает. Для моих читателей, не работающих в ИТ, постараюсь максимально подробно и просто описать такие страшные вещи, как AWS, AZ, DC/OS и Docker.

Сначала про AWS. В далеком 2004-ом году компания Амазон придумала очень интересный бизнес. По миру были (и есть) распространены различные хостинг-провайдеры, у которых можно арендовать оборудование - серверы (физические или виртуальные) и сеть (свичи, маршрутизаторы и т.д.). Амазон решил зайти еще дальше - он стал предлагать предустановленные системы в качестве услуг.

Проще говоря, если вам нужна маленькая база данных на MySQL или Oracle, вы, вместо того чтобы установить все сами (заказать сервер, поставить ОС, поставить туда СУБД, наладить резервное копирование, мониторинг и прочее), заходите на прикольный веб портал, кликаете по нужной СУБД, выбираете размер, идете за кофе, и, когда вы вернетесь, база данных будет готова и ждать дальнейших распоряжений.

У AWS сейчас сотня различных сервисов, от виртуальных серверов и СУБД до сопровождаемых (не вами, что самое прекрасное) очередей сообщений, кластеров для анализа BigData и даже удаленные рабочие столы и CDN.

Для того, чтобы предоставлять вам определенное удобство управления и планирования ресурсов, Амазон создал модель регионов и “зон доступности” (далее AZ).

Регион - определенная географическая область, на которой Амазон предлагает свои услуги. Может считаться как отдельный город, штат или страна. Регионы именуются по стране или географии, “области” и порядковому номеру. В тех же США у Амазона 4 региона - Северная Вирджиния, Огайо, Северная Калифорния и Орегон. Эти регионы именуются как us-east-1, us-east-2, us-west-1 и, ВНЕЗАПНО, us-west-2. Регионы есть и в Европе, например Ирландия (eu-west-1) и Франкфурт (eu-central-1). Делается это для географического удобства (если вы сидите в Амстердаме, то до сервера в Лондоне добраться быстрее, чем до сервера в Австралии) и для соблюдения законов в странах, где вы хотите вести бизнес. Каждый регион состоит из нескольких AZ.
AZ (availability zone, зона доступности) - это один или несколько ЦОДов (центров обработки данных), которые работают независимо друг от друга, но обладают высокоскоростным соединением между собой. Делается это также для отказоустойчивости - если один из AZ придет в негодность, у вас есть еще 2 (или даже больше) ЦОДа.

Теперь немного технических деталей. Когда вы создали аккаунт на AWS и привязали к нему свою кредитку (Амазон берет плату по поминутной тарификации использования их услуг), вы создаете VPC (virtual private cloud) - этакий “свой” ЦОД внутри ЦОД Амазона, привязанный к определенному региону. Серверы и базы данных в дальнейшем будут ставиться как раз на этот самый VPC. Внутри VPC вы создаете “подсети” (subnets), которые живут внутри вашего VPC и привязываются к определенной AZ.

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

Когда вы создаете VPC вы указываете большую сеть (до нескольких десятков тысяч IP адресов). А когда вы создаете подсеть, то в ней вы задаете сеть поменьше, которая в свою очередь является частью большой сети.

Так вот мои прекрасные коллеги в регионе с 3 AZ сделали 3 подсети - 2 маленьких (не знаю зачем) и 1 большую (ЗАЧЕМ?!), в которой и “сидит” бОльшая часть нашей инфраструктуры. Помните, что подсеть привязана к AZ? Первая проблема в том, что если эта самая AZ отвалится, то и 80% нашей инфраструктуры повалится вслед за ней. Люблю своих коллег.

Теперь к моей задаче - мне нужно развернуть отдельный кластер DC/OS для так называемого “тулинга” - ряда небольших (или больших) систем, которые помогают нашим разработчикам и бизнесу делать свое дело. Под тулинг можно подвести системы мониторинга, логгирования, несколько велосипедов, написанных нашими силами, TeamCity (система сборки, тестирования и развертывания ПО) и прочее.

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

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

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

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

Про первый кусок технологий поговорили, теперь о втором - Docker и DC/OS.

Предположим, что вы хотите открыть свой интернет-магазин плюшевых хомячков. Бизнес модель есть, бюджет есть, наемный тыжпрограммист есть.
По “классике”, ваш тыжпрограммист арендует сервер, поставит туда “веб” сервер (система для обслуживания сайтов) и базу данных, чтобы хранить информацию о клиентах и товарах. Здесь надо понимать, что каждая система (веб-сервер, СУБД и тд) это программы. Каждая программа состоит из “своего” программного кода и зависимостей.

Например, для того, чтобы поставить Nginx, на вашем сервере должен стоять GCC (GNU C Сompiler), а для GCC требуется сам C.
Вы поставили СУБД и веб-сервер, написали ваш сайт “ООО Плюшевые хомячки”. Сайт запущен, клиент радостно заходит на него и заказывает себе игрушки. Здорово, правда?

В какой-то момент к вам начинает приходить больше посетителей, и сервер начинает не выдерживать нагрузки (помните, что у вас на 1 сервере и веб сайт, и база данных). Что делать? Заказывать новый сервер и ставить туда ваш вебсайт. А потом еще. И еще. И еще…
Учитывая, что программист все ставит руками, “дублирование” статического сайта начинает занимать больше времени, чем разработка. Это первая проблема.

А потом вы хотите сделать модную систему анализа пользовательского поведения, чтобы определить свою ЦА и начать активно раскручиваться. Для этого нужно опять заказывать сервер, писать под него ПО с кучей зависимостей, а ваша маленькая база и так еле справляется, вы заказываете еще сервер под дублирование БД, настраиваете кластеризацию, ставите перед ними балансировщик, затем дублируете систему анализа данных…

А затем вы разрабатываете “свою” систему email маркетинга, чтобы привлечь еще больше клиентов, ваше приложение становится сложным, и для отказоустойчивости вы применяете очередь сообщений (ЕЩЕ 1 сервер, еще больше ручной работы)…

Уловили идею?

До того как появился Докер, эти проблемы решались такими прикольными способами как управление конфигурациями, автоматизация управления и Infrastructure-as-Code. Идея заключается в том, что в определенных файлах вы описываете, что и как должно быть установлено и где - а затем говорите системе установить это ПО на сервер-1, вот это ПО на сервер-2, а на сервер-3 поменять адрес веб сайта с fluffyhamster.ru на hamsterforlove.ru.
Применение такого подхода сокращает время на настройку и развертывание, но не решает проблему зависимостей - так что поговорим и о ней.

Есть такой прекрасный язык программирования как Python. Я этот язык ну очень сильно люблю и когда программирую, то на нем и только на нем.
У Питона есть две “мастер” версии - 2 и 3. Они друг от друга сильно отличаются, и программа, написанная на Питон 2, вряд ли заработает на Питон 3. Разработчики обычно пишут программы, совместимые с обеими версиями, а умные разработчики переписывают старые программы под Питон 3.

Итак, вот ваш кейс. В вашем онлайн-магазине есть две маленькие программы - одна генерирует электронную рассылку для клиентов, а вторая анализирует пользователей в БД, чтобы выявить интересные для них предложения. Исторически так сложилось, что первая программа была написана на Питон 2, а вторая на Питон 3. Поскольку программы маленькие, заказывать под них отдельный сервер непозволительная роскошь (в простонародье ДОРОГО). Держать их на одном сервере - геморрой с точки зрения “объяснить программе 1 использовать вот этот вот Питон, а программе 2 вот это вот Питон, и НЕ НАОБОРОТ, ТЫ ЧТО НАДЕЛАЛ, У НАС СЕЙЧАС КЛИЕНТЫ ВЗБЕСЯТСЯ, ВЕРНИ КАК БЫЛО, ЧТО ЗНАЧИТ ТЫ УДАЛИЛ 3 ПИТОН, ТЫ НАРКОМАН ЧТОЛИ?”

А когда появился Докер, проблема зависимостей была решена. Я не буду расписывать, как устроен и работает Докер (для неподготовленного читателя это очень сложно, но если очень хочется - пишите мне в личку, постараюсь расписать). Докер создает определенный слой изоляции, где ваша программа запаковывается в определенный “контейнер”. Внутрь вашего контейнера вы устанавливаете все зависимости, добавляете вашу программу, и - вуаля! - ваша программа “запакована”. Запустить ее можно где угодно, достаточно на сервере установить сам Докер и выкатить туда “образ” вашего контейнера.

Докер вообще ВЗОРВАЛ интернет, это была технологическая революция сродни виртуализации. Но, как у каждой новой технологии, у Докера есть свои проблемы.
Например, если вы “убьете” контейнер, все данные на нем пропадают - соответственно он не подходит под базы данных. Впоследствии эту задачу решили с помощью persistent volumes - когда контейнер использует диск самого сервера.
Или другая проблема - контейнер умирает, и вам нужно, чтобы он поднимался сам автоматически.
Или если у вас несколько контейнеров, на которых ваш сайт - как сбалансированно распределять клиентские запросы между ними (помните, что контейнеры иногда умирают).
Или как обновлять ПО. Чтобы запустить контейнер с “новым” ПО, надо остановить контейнер со “старым” ПО, а значит клиенты некоторое время не смогут работать с сайтом.

Чтобы решить такие проблемы, придумали системы контейнерной оркестрации. Самым популярным сейчас является Kubernetes, который из коробки все это делает.

Но мы ребята особенные и используем DC/OS (который на самом деле не контейнерная оркестрация, а система, объединяющая ресурсы нескольких серверов - процессор, память и диск - в один большой pool). Поскольку DC/OS создает определенный уровень абстракции и управления ресурсами, на него сверху ставится Marathon - как раз та самая система оркестрации, которая получает данные о ресурсах от DC/OS и на основе этих данных решает, где и как запускать контейнеры. На DC/OS так же ставится специальный балансировщик, который будет распределять поток клиентских данных и запросов на нужные контейнеры.

Вот как-то так.

C DC/OS у меня следующие проблемы:
1. Я его вообще не знаю.
2. DC/OS довольно сложный. Документация не в полной мере раскрывает, что под капотом, а инструкция по установке предлагает скачать заранее заготовленный шаблон инфраструктуры, чтобы попробовать его у себя локально или в AWS

Как любой уважающий себя специалист, я должен сначала изучить то, что хочу внедрить, поэтому я провожу определенное “исследование”. О нем я расскажу завтра. На сегодня информации хватит. 😉

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

Вчера мы посмотрели прекрасный фильм-расследование про Игоря Сечина, снятый какой-то группой noname’ов. Не буду вдаваться в подробности фильма, политики, коррумпированности и прочего. В фильме была добивающая деталь.

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

В рамках своей программы “Откажись от 3 вещей, мешающих тебе жить” я отказался от Вконтакте, Инстаграма и привычки осуждать других.
Посему у меня к Сечину и претензий нет. Может человек ворует, решает все вопросы через административный аппарат, его менеджерские компетенции вызывают сомнение. Ну да Бог с ним, крепкого здоровья, удачи и успехов. Пусть у него и его детей все будет хорошо.

Но абсолютное неумение тратить деньги просто поражает меня. Я понимаю, что большинству людей присуща самая элементарная жадность. Зарабатывая деньги, вы стремитесь потратить их на себя, свою семью детей и некое общее благополучие. Поэтому осуждать топ менеджера за постройку дома за огромные деньги как минимум… странно.

Сам по себе я хочу следовать “умной” жадности. Если у тебя много денег, вложи их во что-то, чтобы денег стало ЕЩЕ больше.

Но сегодня утром мне пришла в голову интересная мысль. Некоторое время назад я услышал интересную цитату: “Если деньги пришли легко, от них нужно так же легко избавляться.” И вот я думаю - может все эти олигархи, талантливые 21-летние бизнесмены и бизнесвумены и прочая илитка тратит деньги направо и налево просто напросто потому, что они им легко достались, и они всего лишь соблюдают эту традицию?

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

Если мантра “легко получил - легко отдал” имеет место быть, то это объясняет, почему олигархат так бездарно и скучно тратит огромные суммы денег, а наемные C-level менеджеры в коммерческих компаниях ведут себя… скромнее что ли.

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

Итак, моя проблема - надо собрать DCOS кластер, а я понятия не имею, что это вообще такое.

Тут я немного похвастаюсь - за весь свой опыт с самых низов я обрел полезный скилл, как я его называю, native engineering.
Под этим скилом я подразумеваю набор определенных навыков, присущих любому ИТшнику, которые объединяются в одно большое “сакральное знание”. Проще говоря, если вы ИМЕЕТЕ ПРЕДСТАВЛЕНИЕ как “все” (сети, компьютеры, Linux, Windows, базы данных, REST, HTTP вызовы, API вызовы, SSL, configuration management, VCS/SCM, CI/CD и многое многое другое) работает - освоить конкретный продукт, каким бы сложным он ни был, вам не составит труда.

Взять тот же AWS - вас абсолютно не должно волновать, каким образом Амазон содержит свои серверы и системы хранения данных. Вы знаете (и Амазон все время это твердит), что все их сервисы являются API based, а значит любое движение внутри является следствием множества систем, работающих между собой. Вы знаете, что EC2 (виртуальные серверы в облаке Амазона) это виртуальные машины, запускаемые внутри VPC, собираемые из образа ОС, к которым привязывается внутренний и/или внешний IP адрес. Как *конкретно* это делается, вас абсолютно не касается.

Вообще я полюбил Амазон как минимум за то, что он отвязал потребность людей залезать системе под капот.

И вот я приступаю к изучению DCOS. Я знаю, что он дает мне возможность запускать внутри него контейнеры, проводить им проверки и перезапускать, когда те отваливаются.
Чтобы пощупать систему, у меня есть два варианта - запустить кластер локально либо в облаке по заранее заготовленному шаблону.

И как раз тут мой внутренний инженер разбушевался, ведь как это так - запускать что-то, не разобравшись?
Здесь и появляется первое разочарование в себе - DCOS на самом деле очень сложный продукт, состоящий из десятков сложных компонентов, этакий Photoshop из мира DevOps. Если совсем немного окунуться в архитектуру, то получается следующее:
- Есть bootstrap сервер, который хранит в себе дистрибутив DCOS c разными настройками для мастера и агентов.
- Есть мастер - “голова”, которая собирает данные по ресурсам от агентов и распределяет между ними приложения через Marathon
- Есть агент - “тело”, на котором установлен mesos агент, который рапортует мастеру о своих доступных ресурсах.

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

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

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

Но что касается тех, кто хочет залезть с головой в продукт Mesosphere, вот мое предложение:
- Поставьте его локально (как, читайте тут - https://github.com/dcos/dcos-vagrant)
- Поставьте его вручную (есть хорошая подробная документация https://docs.mesosphere.com/1.11/installing/oss/custom/advanced/)

Но на этом мое исследование не заканчивается, о продолжении (как я изучаю способы поднимать его быстро и легко с помощью Infrastructure-as-Code) я расскажу уже на следующее неделе.

Так что всем хороших выходных и веселой пятницы!

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

Все что от вас требуется - расскажите обо мне своим друзьям и коллегам по цеху.
У меня (пока) не стоит планов по монетизации канала. Я парень простой, тихий и не веду канал о лайфхаках или крипте.
Моя выгода - у меня будет больше мотивации писать, писать и писать.
Ваша выгода - больше читателей - больше вопросов и предложений - больше контента.

Спасибо, и давайте оставаться на связи.

Я изучил DCOS до необходимого уровня и понял, как его поднимать. Вариантов несколько, от абсолютно ручного до маленького симпатичного шаблона.

Если я буду поднимать его вручную, мне нужно поднять маленький bootstrap сервер - этакий PXE на максималках. По умолчанию, DCOS предлагает задавать статичный IP адрес для мастера - а это мне совершенно не подходит, ведь в Амазоне подразумевается, что виртуалки падают и нужно уметь поднять все снова.
Если я задам динамический поиск мастера, то мне нужно будет:
- Поставить перед мастером балансировщик.
- Поднять S3 bucket для Exhibitor/Zookeeper
И еще пара бессмысленных сервисов, и все равно я не достигаю моей главной цели - автоматизации всего и вся.

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

Но мне как архитектору и в первую очередь специалисту нужно видеть, как у нас любят говорить, Bigger Picture. А “большая картина” подразумевает, что подход к внедрению новых систем и мощностей надо менять.
Помните, я говорил, что архитекторов не нанимают, когда все хорошо? Это надо помнить всегда, особенно когда вы беретесь за задачу или проект. Смотря на проблему/историю со стороны бизнеса, я осознаю, что проблема не в кластере. Нужно фундаментально менять подход к решению задач, применять новые способы, экспериментировать, но самое важное - убеждаться в их эффективности и added value. Пляшите от этого.

Я потратил на исследование DCOS чуть больше недели, осталось мне по сути немного - найти способ красиво и аккуратно это дело собрать.
Поскольку я очень хочу в Infrastructure-as-Code, я сначала думал задекларировать конфигурацию bootstrap сервера в SaltStack, но уперся в то, что динамическое обнаружение мастеров через bootstrap, как написано выше, тот еще геморрой.
Mesosphere предлагает использовать шаблон Cloudformation, который сам соберет всю инфраструктуру с нуля. Звучит круто, но эта дура собирает все действительно с нуля - от сетевой инфраструктуры до машин. Впихнуть такой шаблон не глядя в уже существующую сетку элементарно невозможно. Остается его перепиливать под свои задачи.

Конечно, я могу собрать свой велосипед, впихнуть всю структуру под Terraform или Ansible, но, раз уж мы засели в Амазоне, имеет смысл копать в сторону Cloudformation.
Я хотел бы добавить элемент политики, как неотъемлемую часть любого исследования, но мои коллеги оказались на редкость податливыми - даже спорить не стали.

Теперь дело за малым - выбросить все лишнее из шаблона и продолжить эксперименты.

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

Раньше как было, я стал круче, если выучил новую штуку - Oracle DataGuard например, HAProxy или Ansible. Изученная «штука» для меня была мерилом успеха.
Почему я так делал? Да потому что открывал вакансии и потом подбирал челюсть с пола, насмотревшись на список требований.

Позже, когда я осознал, что «знать все на свете нереально» взял другое мерило - эти ваши story points из Scrum. Больше «очков» наделал, значит ты весь из себя такой эффективный молодец.

От этого метода измерения тоже пришлось отказаться - производительность не всегда является признаком мастерства.
Если вы за полчаса можете собрать кластер, это еще не значит, что ваш кластер не посыпется, когда количество активных пользователей перевалит за миллион. Можете ли вы тогда считать себя профессионалом? Вряд ли.

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

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

Разрабы стараются доставить максимально возможное количество «фич», в то время как эксплуатация - operations - фокусируется на SLA. Нам в принципе плевать, когда новый функционал увидит свет - главное, чтобы старый работал как часы.

Вдоволь наобщавшись на вчерашнем meet-up’е со всевозможными Scrum мастерами и менеджерами продуктов, я закрепил в мозгу следующую идею: поставка (разработка, сборка, тестирование, развертывание) ПО сродни конвейеру на заводе.

Ваш завод работает лучше всех, когда он стабильно выпускает планируемое количество машин. Каким образом завод добивается повышения количества? Либо открывает больше смен, либо применяет НТП, чтобы повысить эффективность производства.

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

Смотреть на все надо проще. :)

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

Ну вот я и вернулся!

Я тут нарвался на интересный трейлер фильма “Тебя никогда здесь не было” (https://www.kinopoisk.ru/film/tebya-nikogda-zdes-ne-bylo-2017-981957/). Не знаю, чем так крут Хоакин Феникс (да и не важно это), но то что помимо Drive с Гослингом появился еще один крутой фильм, похожий на киноверсию Hotline Miami, меня дико радует. :)

А возвращаясь к моему исследованию - у Cloudformation шаблона, который я ковырял пару дней и даже провел успешное демо своим коллегам, есть несколько недостатков, из-за которых “вот это вот” мы в продакшон ставить не будем.

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

Во-вторых, готовый, пусть и обрезанный шаблон не дает возможности in-place upgrade. Проще говоря, если мы захотим обновить наш стек, то нужно пересобирать весь кластер, а затем перевозить на него приложения. Даже если это будет происходить раз в год, это все равно слишком сложный и долгий процесс.

Так что будем следовать best practices и посмотрим, что из этого получится. Покуда я занят этим делом (которое возможно займет у меня еще неделю другую), жду ваших вопросов и идей по контенту.

По поводу падения Телеграма - помните, что люди, гарантирующие вам 100% uptime/SLA - лжецы и подлецы.

Я все еще жив.

Продолжаю биться головой об DCOS. Если поднять его в multi-master режиме, то он будет плеваться, когда количество мастеров снижается до 1.

Вот прям так и говорит: «У меня тут в настройках должно быть 3 мастера, а по факту один. Не хочу работать!»

Большущий лайк команде Mesosphere за отказоустойчивость.

Накидайте вопросиков, развеюсь, что ли...

Читаю сейчас просто чумачечий пост про управление конфигурациями (https://habrahabr.ru/post/343644/).

Особенно нравится тезис “Зачем писать конфигурацию 15-20 минут, когда можно зайти на сервер и сделать тоже самое за 2”.
Полностью согласен. Если можно сделать что-то быстро - нужно делать быстро.

Если у вас в конторе 1 сисадмин и 5 серверов, то никакие системы автоматизации вам в принципе не нужны (если только вы не адепт “автоматизации ради автоматизации”).
А вот если у вас десятки одних только веб серверов, да еще и где-нибудь в облаке, которые то падают, то поднимаются, то можно и с ума сойти столько ручками все настраивать.

Другой момент - контроль изменений. Infrastructure-as-Code придумали не только для того, чтобы unit тесты ради смеха гонять. Положите конфиги в репозиторий, и каждый инженер будет отправлять туда обновления. Что-то упало - открыли git log/blame и нашли виновника.

У I-as-C гораздо больше применений, нежели выводить из себя инженеров старой школы (К которым у меня всегда была и будет “респект и уважуха”).

Тут предложили немного расписать на тему Infrastructure-as-Code, так что ждите технического контента. ;)

Тут пару раз нарвался на посты на Хабре, переводы английских постов с Медиума, про «плохие» конторы для разработчиков.

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

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

Поскольку я больше времени проработал в конторах, где HeadCount > 5000, чем < 200, я занимался разработкой и сопровождением инфраструктуры на тысячи рабочих станций.
И вот моя, так сказать, «ответочка».

Во-первых, в махровом энтерпрайзе крайне строго соблюдается принцип least privilege - это когда у человека прав ровно столько, сколько ему нужно для его деятельности, не больше и не меньше. Видите ли, если вы каким-то образом скачаете вирус, то меньшее из зол - это получить BootLocker или вечно открывающуюся порнуху. Гораздо хуже, если вы поймаете вирус-червя, который радостно побежит на общий диск и покусает все до чего дотянется (такой случай я видел лично и лично устранял последствия, блокируя файлер и откатывая до вируса до атаки, уничтожая несколько часов работы 6 тысяч человек). Мало того, что подобного рода откаты это потеря огромных денег, это еще и ответственность инженеров.
Если разраб скачает «косячную» библиотеку с вшитым кейлоггером или трояном, виноват в этом будет админ и ТОЛЬКО админ.
Так что не стоит удивляться строгости админов, которые ничего не разрешают делать локально. Сервер для разработки - пожалуйста, рутовый доступ туда - тоже пожалуйста, проблем ноль. Ломать свою машину - ни-ни.

Никакое законодательство неспособно «заставить» разработчика по закону отвечать за то, что он превратил свой ноутбук в рассадник заразы, а учитывая, что не все разрабы одинаково полезны, слепо доверять им тоже никто не станет. Остается соблюдать строгую compliancy и разрешать устанавливать только проверенный софт - без исключений.

Во-вторых, софт для разработки и локального тестирования пишут в основном для компаний, где у разрабов уже есть права локального администратора. “Запаковать” такой софт через какой-нибудь System Center или, еще хуже, групповые политики, задача очень сложная и может занять немало времени.

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

Ну поговорим теперь о технике. Этой вашей Инфраструктуре-как-Код (далее IaC).

В те давние времена, когда каждый админ автоматизировал свою работу в баш скриптах (а особо крутые в питон скриптах), людям нужно было вести журнал изменений (помните, что про Agile никто не знал, и все поголовно были ITILовцами).
В основном в качестве трекера изменений использовали ticket-систему, а в конфигурацию систем и серверов вносили номер ticket’а, по которому инициировалось изменение. Менеджер по изменениям мог видеть номер ticket’а в конфигурации почтового сервера, зайти в систему и посмотреть, кто это придумал, кто это реализовал, ну и, собственно, зачем.

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

Эта и много других проблем легли в основу практики IaC.

Вкратце IaC это подход, в котором инженеры относятся к своей инфраструктуре как к исходному коду приложения. А раз наша инфраструктура теперь приложение, то и применяются к ней все best practices разработки, а именно:
- держим “код” инфраструктуры в центральном репозитории, изменения к которому делаются через commit/push или pull/merge requests
- держим несколько “окружений” инфраструктуры: локальное (development), test/stage и production.
- держим код в чистоте - PEP8, Linting, etc
- гоняем тесты, в том числе интеграционные.
- проводим Code Review.
- все это проходит через CI/CD систему, после чего выкатывается на нужное окружение.

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

Зачем это делается? Да затем, что в больших и маленький конторах за разные части инфраструктуры отвечают разные “роли” инженеров.
Сетевики правят конфиги фаерволлов и маршрутизаторов, ДБАшники тюнят базы данных, “обычные” админы накатывают обновление на серверы, релиз инженеры релизят, безопасники безопасят… в общем, много всего делается.

Можно уйти в дебри применения IaC в классических ЦОДах, где кругом хардкорный bare metal и вот это вот все.

Но поскольку у нас тут 21-ый век, облачные вычисления, managed services и хипстеры с макбуками, мы не будем лезть так глубоко.
Видите ли, если вы подсели на героин Амазона, Микрософта или Гугла, все эти роутеры, свичи, прошивки металлических серверов, гипервизоры виртуализации вас не касаются. Ими по-прежнему управляют, но не вы. Вы к настройкам сетки не прикоснетесь никак.

В вашем случае каждый кусок инфраструктуры вам доступен в качестве ресурса. Таблица маршрутизации - ресурс. Сети и подсети - ресурс. Базы данных - ресурс. Виртуальные машины - ресурс. Правила фаервола, вы не поверите, тоже ресурс! Ну и так далее.

Поэтому в увлекательном мире AWS/GCP/Azure вам нужно организовать только две группы: ресурсы и приложения.
Для того, чтобы управлять ресурсами есть много разных прикольных штук - от нативных (Cloudformation для AWS, Resource Manager для Azure и Google Cloud - причем это РАЗНЫЕ Resource Manager’ы!) до кастомных 3rd party штучек, таких как Packer, Ansible (да, он вам и сетки с подсетками сделает, ну не прелесть ли?), Terraform, Salt-Cloud и т.д.

А вот для управления приложениями служат наши старые добрые друзья, которые вам всем знакомы - Chef, Puppet, Ansible, Salt, CFEngine, ну и что я там еще мог забыть.

Нет смысла писать какие SCM системы применять. Git/SVN/CVS тут знают все (ну почти все). Для Linting тоже есть огромная масса финтифлюшек - взять например ansible-lint и hiera lint.

Для тестов вашей инфраструктуры существует ряд фреймворков - serverspec. testinfra… - всех не счесть. Если написанные утилитки вас не устраивают, то тесты можно написать и самому в том же скрипте.

Вот например делаете вы LAMP (Linux-Apache-MySQL-PHP) стек. Как эту инфраструктуру протестировать? Да очень просто.
Когда ваша инфраструктура готова? Когда нужные пакеты установлены, сервисы запущены, порты прослушиваются. Обычным башем это делается за 15 минут.

В итоге, в репе лежат ваши описания инфраструктуры. Jenkins/Teamcity/u-name-it гоняют сборки раз в Х минут и при каждом коммите. Не проходит сборка - орем в Slack, откатываем этот коммит и работаем дальше. Когда все тесты прошли и обновление инфраструктуры выкатили - системы управлениям ресурсами сами все сделают.

Получаем уведомление, что все прошло успешно (или нет), радуемся (грустим) и идем наливать себе кофе.
Если у вас все хотя бы процентов на 80% делается как описано выше - поздравляю, вы официально практикуете Infrastructure-as-Code.

Вроде ничего не забыл. Есть что добавить/спросить? Милости прошу - @ThomasStorm