Запускаем запись на двухдневный интенсив по Terraform, обучение пройдет 24–25 апреля. Интересно будет всем, кто работает или планирует работать с облачной инфраструктурой и продолжает разворачивать её в ручном режиме.

Что здесь интересного?

Мне очень нравится Terraform.

Помимо CloudFormation для AWS и OpenStack Heat, это один из самых полезных инструментов с открытым исходным кодом, обеспечивающих развертывание и настройку инфраструктуры на любой платформе. Однако есть один способ работы с Terraform, который меня беспокоит:

terraform plan # «Выглядит нормально; в работу!» — подумал инженер.
terraform apply

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

А если развертывание производится из-под всевидящего и всемогущего production-аккаунта или охватывает дата-центр целиком? Мне кажется, это весьма рискованно.

Интеграционное и юнит-тестирование способно решить эту проблему. Вы, наверное, спросите: «Юнит-тестирование — это как для программ?» Да, то самое юнит-тестирование!

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

Как начать пользоваться terraform, развернув локально приложение поверх minikube, и потом запустить его поверх kubernetes в cloud.google.com

— Почему у нас всё упало?
— Потому что вы откатали это на стенде, всё протестировали, а потом развернули на проде. Вот у вас настройка, которая не попала в инструкции, и жила только в голове старого админа.

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

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

Вместе с трендом «распила» больших монолитов на небольшие микросервисы в эксплуатацию веб-приложений пришёл тренд на оркестрацию контейнеров. Сразу после хайпа на Docker поднимается хайп на инструменты запуска сервисов поверх Docker. Чаще всего говорят о Kubernetes, однако его многочисленные альтернативы в настоящем также живут и развиваются.

Вот и в iFunny задумались о пользе и ценности оркестраторов и в итоге выбрали Amazon Elastic Container Service. Вкратце: ECS является платформой управления контейнерами на EC2 instances. О подробностях и опыте в бою читайте ниже.

Закон Хофштадтера: Любое дело всегда длится дольше, чем ожидается, даже если учесть закон Хофштадтера.
— Дуглас Хофштадтер, Гёдель, Эшер, Бах

Изучая свои книги

I'd like to share my story about migration an application to Openshift. Also, as a result, I will compare some of the most popular solutions and tools for managing your application inside Openshift. It is the transcription of my presentation at kubernetes SPB meetup #3.

Я хочу рассказать история, как запускали приложение в Openshift. Так же по ходу пьесы рассмотрим утилиты для управления приложением внутри Openshift. Это расшифровка выступления на kubernetes SPB meetup #3..

Проблема

Какое-то время назад мы сделали безагентский (Agentless) мониторинг и алармы к нему. Это аналог CloudWatch в AWS с совместимым API. Сейчас мы работаем над балансировщиками и автоматическим скейлингом. Но пока мы не предоставляем такой сервис — предлагаем нашим заказчикам сделать его самим, используя в качестве источника данных наш мониторинг и теги (AWS Resource Tagging API) как простой service discovery. Как это сделать покажем в этом посте.