Дисклаймер: Я написал такую статью, какую сам хотел бы прочитать полгода-год назад, когда мы стартовали миграцию в облако. Мне бы она здорово помогла сэкономить силы, время и нервы – надеюсь, теперь поможет кому-то ещё. Здесь нет исчерпывающей экспертизы, только немного моего опыта для конкретных условий и наработанные мною решения и инструменты.
Критика и дополнения приветствуются.
Около года назад я переквалифицировался из .NET-разработчика в SRE. В этой статье делюсь историей о том, как группа опытных разработчиков отложила в сторону C# и пошла изучать Linux, Terraform, Packer, рисовать NALSD и строить IaC, как мы применяли практики экстремального программирования для управления инфраструктурой компании, и что из этого вышло.
Представлять инфраструктуру в виде кода в повторяемом текстовом формате — простая лучшая практика для систем, с которой не нужно мышевозить. За этой практикой закрепилось название — Infrastructure as Code, и пока что для ее осуществления, особенно в AWS, есть два популярных инструмента: Terraform и CloudFormation.
Сравниваю опыт работы с Terraform и CloudFormation
До прихода в Twitch (он же Amazon Jr.) я трудился в одном стартапе и года три использовал Terraform. На новом месте я тоже вовсю использовал Terraform, а потом компания продавила переход на все а-ля Amazon, включая CloudFormation. Я усердно разрабатывал лучшие практики и для того, и для другого, и оба инструмента использовал в очень сложных рабочих процессах в масштабах организации. Позднее, вдумчиво взвесив последствия перехода с Terraform на CloudFormation, я убедился, что Terraform, наверное, — лучший выбор для организации.
Привет! Раньше я жаловался на жизнь в парадигме Infrastructure as code и ничего не предлагал для решения сложившейся ситуации. Сегодня я вернулся, чтобы рассказать, какие подходы и практики помогут вырваться из бездны отчаяния и вырулить ситуацию в правильное русло.
GitLab CI — это эффективный инструмент для самых разных сценариев, включая инфраструктуру как код. GitLab можно использовать с разными инструментами, но в этой демонстрации мы возьмем Ansible, потому что именно его чаще всего используют разработчики при подходе «инфраструктура как код». Вот демо с двумя маршрутизаторами из курса по сетям Ansible.
Прим. перев.: После недавней публикации материала о методах pull и push в GitOps мы увидели интерес к этой модели в целом, однако русскоязычных публикаций на эту тему оказалось совсем мало (на хабре их попросту нет). Посему рады предложить вашему вниманию перевод другой статьи — пусть и уже почти годичной давности! — от компании Weaveworks, глава которой придумал термин «GitOps». В тексте поясняется суть подхода и ключевые отличия от уже существующих.
Год назад мы опубликовали введение в GitOps. Тогда мы рассказали, как команда Weaveworks запустила SaaS, целиком основанную на Kubernetes, и разработала набор предписывающих лучших практик для развертывания, управления и мониторинга в среде cloud native.Читать полностью »
Хотел бы рассказать про новый CLI tool который я написал для решения одной старой проблемы.
Terraform уже давно стал стандартом в Devops/Cloud/IT сообществе. Вещь очень удобная и полезная чтоб заниматся infrastructure as code. Есть много прелестей в Terraform а так же много вилок, острых ножей и граблей.
С Terraform очень удобно делать новые вещи и потом ими управлять, менять или удалять. А что делать тем у кого есть огромная инфраструктура в облаке и не создано через Terraform? Переписывать и пересоздавать все облако как то дорого и небезопасно.
Я сталкивался с такой проблемой на 2 работах, самый простой пример когда хочешь что все было в гите виде терраформ файлов, а у тебя 250+ бакетов и писать их для терраформа руками как то много.
Есть issue еще с 2014 года в terrafom которую закрыли в 2016 с надеждой что будет import.
Вообщем все как на картинке только справа налево
Читать полностью »
Учи.ру — онлайн-платформа для школьного образования, более 2 миллионов школьников, регулярно решают у нас интерактивные занятия. Все наши проекты хостятся полностью в публичных облаках, 100% приложений работают в контейнерах, начиная от самых маленьких, для внутреннего пользования, и заканчивая крупными продакшенами на 1k+ запросов в секунду. Так получилось, что у нас 15 изолированных докер-кластеров (не Kubernetes, sic!) в пяти облачных провайдерах. Полторы сотни пользовательских приложений, количество которых постоянно растет.
Я буду рассказывать очень конкретные вещи: как мы переходили на контейнеры, как управляемся с инфраструктурой, проблемы с которыми столкнулись, что заработало, а что нет.
В процессе доклада мы обсудим:
Кому интересно, прошу под кат.
Любой компании, разрабатывающей софт, нужны тестовые среды, приближенные к продакшн-окружению. Особенно это актуально для коробочного ПО, у которого длинный цикл релизов.
Многие проблемы построения тестовых сред решает их размещение в облаке. Мы расскажем про возможности тестирования на нашей облачной платформе Mail.Ru Cloud Solutions (MCS). Но часть из того, что мы расскажем, верна для любого облака.
Читать полностью »
В IT-проектах код пишут все. Инженеры с помощью нескольких строк управляют Kubernetes кластерами, разгоняют облака Terraform'ом и ворочают тонны конфигураций на Ansible, Chef и Puppet. QA пишут понятные бизнесу тестовые сценарии на Spock и Cucumber. Аналитики свободно, часто лучше разработчиков, разговаривают на SQL. Проектная документация в форматах Markdown, AsciiDoc или LaTEX "компилируются" в нужный формат на билд-сервере. Ну а сами разработчики, эти укротители кода, владеют сразу россыпью языков на каждый жизненный случай — клиентский, серверный, скриптовый, функциональный и пр.
Код уже давно перестал быть загадочной тарабарщиной и теперь в том или ином виде доступен и понятен многим, даже премьер-министрам. И весь этот код участвует в стандартном жизненном цикле — находится под управлением VCS, подвергается code review, автоматизированному тестированию, CI, CD. Используются общие инструменты и подходы, метрики производительности и качества. А все вместе это носит гордое название — "Everything as code".
Однако мир БД традиционно стоит особняком вдалеке от этой феерии прогресса и технологий. Процесс разработки и сопровождения БД не меняется годами и продолжает вселять ужас и страх в разработчиков, администраторов и пользователей по всему миру. Но возможно ли представить БД в виде обычного кода? Приблизиться к основному процессу разработки, использовать общие инструменты и подходы? Об этом под катом.
