Я подумал, что неплохо было бы сегодняшний день посвятить контейнерам. А то как-то так получилось, что DevOps-DevOps, а о контейнерах ещё ничего не было - нелья так.

Чтобы ввести в курс дела (мало ли) статья о контейнерах вообще. Отличиях виртуализации от контейнеризации и почему это всем так сначала понравилось.

Дальше блог о том, как человек перенёс своё окружение разработчика из Vagrant в Docker с наглядными практическими рекомендациями.

Ну и напоследок ещё один блог с примерами для разных языков программирования
#containers #docker

Не свойственно для этого канала, но обе статьи на русском. Они достаточно старые, но, во-первых, не потеряли своей актуальности, во-вторых, помогают вникнуть быстро вникнуть в суть дела, в-третьих, когда хайп вокруг Docker начинался и был в разгаре, этого канала ещё не было 🙂

Контейнеры в общем-то по-одиночке запускать скучно. Даже для простеньких проектов их необходимо обычно несколько. Поскольку аргументы у Docker достаточно муторные, даже на локальном хосте имеет смысл пользоваться docker-compose (он, кстати, описан в третьей статье)

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

А уже в следующей статье он сравнивает известные оркестраторы по разным критериям, таким как сеть, управление дисками, деплой и проч. Очень классно получилось - почитайте!
#containers #docker #swarm #kubernetes #mesos #nomad #rancher

Как говорится, молния!

По ссылке собрано 435 бесплатных онлайн курсов по программированию и компьютерным наукам, которые можно пройти в июне.

При чём большинство курсов ещё и имеют оценку по пятибальной шкале.

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

И тут бы хотелось остановиться на Kubernetes, как одном из самых популярных.

Когда я разбирался с языком Go, мне очень помогал ресурс GoByExample. Там на простых примерах расcказан синтаксис, возможности и особенности языка.

OpenShift team сделали то же самое для Kubernetes! Kubernetes By Example даёт примеры основных действий, которые можно делать в "Кубере" с пояснением тех или иных действий.

"Окей", - скажете вы, - "И где мне это запускать?" Но и тут не беда! Потому что существует проект Minikube, который позволяет запускать Kubernetes локально поверх виртуальной машины.

Дерзайте!
#kubernetes

Amazon открыли публичный доступ к AWS Greenglass

Это сервис, который позволяет запускать код AWS Lambda на подключенных IoT устройствах таких как Raspberry Pi или же EC2 инстансах в качестве среды разработчика

Подробнее по ссылке

В продолжение вчерашнего.

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

Поэтому я вам иногда буду подкидывать интересных людей оттуда. И первой в списке пойдёт Джулия Еванс aka @b0rk — инженер и художница, которая рисует прекрасные скетчи по технической тематике и даже выпускает свой самиздатный журнал. И ведёт блог

Ну а по этой ссылке статья про Kubernetes (конечно же со скетчами!)
#kubernetes #twitter #people

Журнал, кстати, можно заказать в бумаге. Правда, я боюсь предположить, сколько будет стоить доставка из США.

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

Часть I: История внедрения, что может пойти не так, чего необъодимо избегать и чем Docker заменить.

Часть II: где запускать Docker. Плюсы, минусы, подводные камни разных Host OS

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

P.S.
А ещё мы сегодня выловили интересный баг Джавы. Про него как-нибудь позже напишу

Эволюция деплоя в Reddit - отличная статья которую стоит прочесть и скажем сравнить прогресс админов Reddit с вашим - https://redditblog.com/2017/06/02/the-evolution-of-code-deploys-at-reddit/

Как бы Telegram не был хорош, используют его в основном на постсоветском пространстве.

В Европе же и Северной Америке эту роль на себя берут другие мессенджеры. А в технической сфере особо популярны Slack-community. Преимущество их в том, что мало того, что Sack позволяет создавать кучу каналов внутри одного чата, так ещё и имеет возможность давать фидбэк, в отличии от тех же каналов Telegram.

Поэтому делюсь с вами сборником из тысячи Slack-communities на различную тематику.

Ну автор сборника утверждает, что тысяча — сам я не считал.

Ну и бонусом карта самых популярных мессенджеров по регионам
#slack #people #culture #tech

Сегодня у нас достаточно старая статья (ей больше года) про сетевой уровень Интернет.

Статься большая: ~ 7000 слов, но очень интересная. Особенно в мире, где люди работают на высоких уровнях абстракции и не всегда задумываются о том, как сигнал идёт по кабелю, как сделать сеть между миром и Австралией и почему кабель не грызут акулы.
#hardware #internet #networking

И вопрос вдогонку: имеет ли смысл переводить статьи (хотя бы некоторые)?

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

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

➕ - переводы Ок
➖ - и так сойдёт

Ну и сразу хочу предупредить, что переводить вот прямо всё я не буду — это просто бессмысленно для простых анонсов, репозиториев на GitHub и некоторых других штук

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

Это то, что играет огромную роль в подходе Infrastructure as s code, хотя, в принципе, можно обходиться без неё, но в большинстве компаний вы что-то подобное вы таки найдёте.

Pets vs Cattle: статья, которая наглядно объясняет саму концепцию и для чего всё она нужна.

По три слова о самых популярных сервисах: Chef, Puppet, Ansible, Salt, PowerShell, Cobber (не совсем управление конфигурацией), CFEngine

Размышления о том, каким должен бы был быть инструмент для управления конфигурацией. В двух словах: stateless & declarative

Система управления конфигурациями, написанная на Go. С интересной идеей, но ужасной реализацией (там куча багов). Так что это скорее для общего ознакомления. GitHub

Ещё одна сравнительная статья. На этот раз на русском и только про Ansible vs Salt. Однако, в этой статье присутствует фраза о первичном назначении Ansible: закрытии бреши между Cobbler и Puppet. Хотя с тех пор проект сильно вырос.

И наконец, видео выступления с OpenStack Summit 2015. Да, давно это было (зато футболка с саммита жива до мих пор!) Однако, основные концепции то не поменялись.
#configManagement #puppet #chef #ansible #salt

Express news, так сказать.

В версии Terraform 0.10 все провайдеры собираются вынести из единого бинарника (terraform-core).

Собственно что такое Terraform: ещё один продукт HashiCorp, который добавляет ещё один уровень абстракции над API облачных платформ и позволяет вам указывать состояние инфраструктуры в виде файла(ов) конфигурации. Infrastructure as a Code as is. Если вам знаком Vagrant (тоже продукт Hashicorp) то вы можете представить, как это выглядит. Разница в том, что Vagrant обращается непосредственно к гипервизору, так что он хорош для локальных экспериментов, но не для большой инфраструктуры.

За время своего существования, Terraform вырос и кроме поддержка API известных платформ (AWS, Azure, OpenStack, GCE) у них есть поддержка других вещей, например, DNS (Neustar) и почие.

По большому счёту, всем, что имеет API, можно манипулировать с помощью провайдеров. Вот заметка моего бывшего сотрудника о том, как написать Terraform provider своими руками.

И ещё один хороший блог в том числе о Terraform. Его автор даже книгу о нём написал. Правда, я не дошёл до неё ещё, всё в рид-листе висит, но вот к записям в блоге частенько обращался.

И ещё один технический блог от Charity Majors — интересного человека в Twitter — о впечатлениях, связанных с сабжем.
#terraform #hashicorp

Появились видеозаписи докладов с monitorama pdx 2017. Рекомендуется к просмотру всем кому не безразличен мониторинг и/или time series.

https://vimeo.com/channels/1255299
#monitorama #monitoring #video #tsdb #timeseries

Вот мне начали приходить запросы о темах. И первая звучала как: "что нужно знать о DevOps бекэнд программисту, чтобы наступило вселенское счастье".

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

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

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

- сокращайте срок релиза. Релиз вообще не должен быть каким-то событием. Аж в 2009 году John Allspaw и Paul Hammond из Flickr представили доклад 10 deploys per day. Это было 8 лет назад и сейчас колличество деплоев в компаниях возрало в разы. Короткие релизы позволяют быстрее найти проблему (если появится) исправить её или в крайнем случае релиз откатить

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

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

- учитесь на своих ошибках. Amazon представил. Есть метод "5ти почему". Например, недавние проблемы с AWS S3 был спровоцирован человеческим фактором, но никого после этого не уволили. Потому что как говорится "мы только что вложили несколько миллионов в твоё обучение"

- автоматизируйте это. Это к слову об ускорении времени между релизами. Для этого уже есть куча инструментов: CI/CD сервисы (о них как-нибудь напишу отдельно), сервисы для Continuous Code Analysis и прочее

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

В довесок рекомендую вам почитать The Phoenix Project — единственную известную мне художественную книгу о DevOps. Плюс, Site Reliability Engineering. Есть ещё куча книг по данной тематике. Которыми я буду с вами по ходу пьесы делиться.

И да, как я говорил, мне можно писать и спрашивать об интересующих вещах. Ну а я в свою очередь расскажу о чём смогу в силу своей экспертизы. Вот вам даже специальный бот для этого: @AskCatOpsBot
#culture #devops

17 июня (эта суббота) пройдёт очередной Kyiv DevOps meetup

У меня, к сожалению, быть там не получится. Однако, на таких меропритиях можно встретить кучу интересных людей, которые с радостью поделятся боевым опытом и всякими best practices. Да и докладчики интересные.

В общем, будет полезно не только матёрым 0дминам, но и разного рода разработчикам, студентам и желающим "вАйти". Кроме того, вся эта движуха бесплатна, по крайней мере раньше так было. Главное — зарегистрироваться через MeetUp. Ссылку я скинул.

Welcome!
#event

Как-то мне рассказали о такой интересно штуке, как exception driven development. Это когда вы начинаете налавливать эксепшены и просто таки строить на них всю логику приложения. После такого в логе можно найти что-то типа:

 This is not an error. Even foobar captured

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

А пока почитайте про другие пагубный паттерны в статье с прекрасным названием "Asshole-driven development"
#anti-pattern #development

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

Зато Puppetlabs тут сделали опрос, по которому вы можете определить, насколько глубоко DevOps практики засели в вашей компании.

Там всего 17 вопросов и мне выпало 'Advanced'. Хотя у нас далеко не все хорошо, там такой опрос, что получить не 'Advanced', наверное, сложно

С другой стороны, на основании подобных опросов они скорее всего делают ежегодный отчёт, так что ваш голос улучшит выборку