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

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

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

Я изучил 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

Возвращаясь к разговору о плоской земле (https://t.me/manandthemachine/181).

Нашел тут увлекательное чтиво на эту тему: https://secretmag.ru/trends/whatsup/ilon-mask-i-nasa-vrut-pochemu-v-xxi-veke-lyudi-veryat-v-ploskuyu-zemlyu.htm

Прочитать стоит хотя бы ради этих строчек: “Образумить рэпера пытался известный астрофизик и популяризатор науки Нил Деграсс Тайсон. «Полярная звезда не видна после полутора градусов южной широты. Ты либо никогда не был к югу от экватора, либо никогда не смотрел на небо», — написал Тайсон рэперу в Twitter. Столкновение в соцсетях переросло в настоящий рэп-баттл: B.O.B. записал дисс на Тайсона, а учёный — на рэпера.”

Ученый записал дисс на рэпера.
А еще ругаются, что я рэп-баттлы посматриваю. 🙁

Знаете, что еще круто в моей новой роли?

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

Сегодня предстоит посмотреть аж целых 3, общей длиной в 3.5-4 часа.
Это как смотреть сериалы, и чтобы вам за это платили (правда сериалы все же интереснее смотреть).

Но это все мелочи жизни. Приеду на работу, поделюсь чем в итоге закончилось мое исследование, и что буду делать дальше.

Учишься 5 лет на системного инженера, идешь работать на третьем курсе, изучаешь кучу всяких штучек, ходишь на дорогостоящие курсы, сдаешь экзамены…

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

https://tjournal.ru/68889-deputaty-gosdumy-o-telegram-i-peredache-klyuchey-shifrovaniya

Вот я вас снова обманул. :(
Завтра напишу, честное слово!

Как вы помните, мне пришлось немало повозиться с десятком разных способов развертывания DCOS.

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

CloudFormation не решал моей проблемы, дефолтный Bootstrap метод тоже (много надо делать руками). В итоге на встрече с командой шеф велел не заморачиваться апгрейдом. Мы можем себе позволить делать это руками (DCOS выпускает новую версию в лучшем случае раз в полгода), а самое важное это отказоустойчивость агентов, потому что customer impact.

Так что вот вам еще совет - не надо стремиться обеспечить 100% uptime системам, которые не влияют на KPI и SLA,

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

У шаблонов DCOS на Terraform и CloudFormation есть две большие разницы. Если CF нужен строго для ознакомительных целей, то Terraform был собран фанатами и поддерживается, собственно, самими фанатами. Ребята потратили немало времени, чтобы это собрать, обкатать на разных платформах, и обновляют его с каждой новой версией.

Запустить кластер мне удалось с полпинка с минимальным количеством ошибок. Не смотря на то, что я не пользовался Terraform раньше и старался держаться подальше от продуктов Hashicorp по User Experience соображением, я заметил, что Terraform обладает неоспоримым преимуществом перед CloudFormation.

Когда вы создаете CF стек, для того чтобы прогнать его еще раз, вам нужно что-то изменить - либо в самом стеке, либо в его параметрах. При попытке собрать уже собранный стек еще раз, CF пошлет вас куда подальше (и будет прав). Это правильная политика, но если вы затем ручками удалите какой-нибудь ресурс, то прогнать стек еще раз не удастся. В интернете люди предлагают добавить параметр инкремента и обновлять его каждый раз, когда захочется повторить сборку.
Касательно EC2 это можно решать через ASG, но в остальном приходится довериться здравому смыслу ваших коллег (что у них не хватит ума что-то радостно стереть просто так.)

Terraform же “запоминает” ресурсы, которые создал, и когда вы делаете terraform apply, он побежит к AWS, проверит ресурсы, а потом скажет вам, что он собирается делать. Это очень здорово - собранные им ресурсы записываются в метаданные, и если вы удалите EC2 instance или S3 bucket или RDS instance руками, то Terraform потом его вам еще раз соберет, и мало того - если удаленный ресурс являлся зависимостью для других, то он и их пересоберет!

Я теперь вынужден пройти парочку обучений по Terraform, но предварительные результаты исследований мне нравятся. Мой старший коллега в прошлом много работал с ним и подтвердил его надежность как IaaC утилитки, а шеф дал добро на применение любого решения, которое fit for purpose.
На этом можно сказать, что моя катавасия с DCOS подошла к концу. Я еще далек от завершения поставленной задачи (кластер еще надо запустить, протестировать и перенести на него наш тулинг), но полученный опыт бесценен.

Пока писал этот пост, официально запретили Телеграм в РФ. В интернете много инструкций как обойти блокировку.

Оставайтесь на связи, учите английский и занимайтесь саморазвитием, как личностным, так и профессиональным.

На всякий случай. ;)

Тут подкинули новость, что из-за Zello заблокировали (или не заблокировали… пес их разберет) IP адреса AWS и GCP (облачный провайдер от Гугла).

Не буду вдаваться в политику, но хочу напомнить товарищам чиновникам и остальным ЛПРам (лица, принимающие решения), что в последний раз, когда у Амазона что-то отказывало, проблемы начинались у множества людей в абсолютно разных местах.

Самой офигеной аварией был отказ сервиса S3 в регионе us-east-1 (Северная Вирджиния). Это привело к каскадному отказу с эффектом домино - не запускались EC2 инстансы, Lambda не могла работать из-за нерабочего S3 API и т.д.

Подробно об этом отписался сам Амазон - https://aws.amazon.com/message/41926/

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

Так вот если РКН *действительно* заблокирует *все* публичные адреса Амазона, пользоваться любым сервисом, который на нем хостится, будет невозможно.

Теперь я понимаю, почему Apple и Facebook держат свои дата-центры.

Ребятки, я тут улетаю навестить семью на пару недель. Буду ли писать или нет - пока не знаю. Если хотелось бы о чем-нибудь прочитать - вы знаете, что делать. 😉

Между делом немного саморекламы.

Мы с моими друзьями-приятелями запустили наш проект. Кто не помнит, это проект по автоматизированной торговле на рынке криптовалют.

Если вы из разряда людей “буквы нафиг, читаем цифры”, то вот вам цифры - stats.gsmg.io.
Ежели хотите познакомиться с нашей уютненько community, то милости прошу на slack-invite.gsmg.io