Вы начинающий инженер по DevOps / инфраструктуре? Или вы инженер, заинтересованный в получении дополнительных навыков, которые помогут оптимизировать свое развитие? Или вы настолько ненавидите DevOps, что хотите узнать, каких навыков следует избегать? Вы попали в нужную статью! Я обнаружил, что есть несколько инструментов и платформ, которые я использую снова и снова. Поэтому я решил перечислить самые полезные навыки, которые я усвоил, а также на что следует обратить внимание, когда вы изучаете эти навыки.

1. AWS / GCP / Azure

Это в первую очередь самый важный навык. Все компании, в которых я работал, размещены в облаке, и если ваша компания размещена на локальном сервере, выберите ЗАПУСК (шутка!). Однако хорошо то, что как только вы изучите одну облачную платформу, другие облачные платформы будут очень похожи, только с другой терминологией. Например, вместо GCP Dataproc используется AWS Elastic MapReduce, а вместо GCP PubSub - AWS SNS.

💡 Изучая эти облачные платформы, обратите особое внимание на:

  1. IAM и разрешения: все приложения должны иметь разрешение IAM, а разрешения по умолчанию обычно являются наименее разрешительными.
  2. Сеть (VPC, подсети, правила брандмауэра / группы безопасности): для всех приложений обычно требуется настройка сети.

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

  • IAM (у моего приложения нет необходимых разрешений))
  • Сеть (у моего приложения нет нужных правил VPC, подсети или групп безопасности / правил брандмауэра)
  • … Или, наконец, мой код

Другие полезные сервисы, которые стоит изучить, - это «бессерверные» сервисы, такие как AWS Lambda, AWS Elastic Beanstalk, GCP App Engine или GCP Cloud Function. Часто вам нужно развернуть простые API-интерфейсы микросервисов, которые не оправдывают сложную инфраструктуру. В других случаях вы захотите быстро разработать MVP или вам просто понадобится среда быстрой разработки.

2. Terraform

Изучите Terraform!… Или какую-либо другую инфраструктуру в виде фреймворков кода, таких как GCP Deployment Manager или Cloud Formation. Все компании, с которыми я работал, которые работают в облаке, управляют своей инфраструктурой с помощью IaC, и если ваша компания этого не делает, то ВЫПОЛНЯЙТЕ (на этот раз я не шучу!). В противном случае вы просто будете щелкать графический интерфейс для создания инфраструктуры, подготовка будет подвержена ошибкам, ничего не будет легко воссоздать. Этот список можно продолжить.

Теперь вы можете подумать: «А как насчет изучения Chef, Puppet или Ansible?» Хотя это похоже, это не одно и то же. Chef, Puppet и Ansible обычно настраивают и управляют программным обеспечением на существующих серверах, в то время как Terraform создает серверы и настраивает их. Изучение любого из них было бы полезным, поскольку применимы многие из тех же концепций «Инфраструктура как код».

💡 Когда вы изучаете IaC, обратите внимание на

  1. Документация. И когда в документации написано, что вы собираетесь что-то уничтожить. Я серьезно! IaC обладает огромной силой - он может создавать, но также и уничтожать огромные фрагменты архитектуры при неправильном изменении кода. Простая установка неправильной однострочной конфигурации для службы может в конечном итоге уничтожить ее и все данные внутри нее.
  2. Структурирование кода. Написание terraform может показаться простым, поскольку может показаться, что для этого достаточно просто найти документацию для вашего ресурса. Но изучение того, как структурировать большие объемы кода терраформирования, и изучение передовых методов часто упускается из виду. Следует ли структурировать репо по ресурсам? Следует ли сгруппировать все лямбда-ресурсы вместе? Или вам следует сгруппировать ресурсы по службам (например, следует ли сгруппировать все ресурсы, связанные с my-cool-service, вместе)?

Также полезно узнать, как искать в Github примеры, относящиеся к вашему ресурсу. Примеры покажут вам различные возможности инициирования ресурса (документы терраформирования также помогают, но иногда в них отсутствуют примеры того, как на самом деле использовать атрибут). Вот пример для начала: https://github.com/search?q=extension%3Atf+aws_elasticsearch_domain&type=Code Это ищет упоминания ресурса aws_elasticsearch_domain в файлах с .tf расширение.

3. CICD (CircleCI, Github Actions, Jenkins, Travis CI и т. Д.)

Ура, теперь вы знаете об AWS и о создании серверов в AWS с помощью Terraform - но как насчет развертывания на этих серверах? CICD имеет решающее значение, потому что каждое приложение нужно будет где-то развернуть в какой-то момент, и лучше, если вы будете делать это постоянно. Более того, хороший конвейер CICD может помочь вам заблокировать развертывание в производственной среде, чтобы рандомные пользователи не могли развертывать ее в производственной среде из своих командных строк. Часть CD обычно сложнее, чем CI, но с каждой из них связаны лучшие практики. В зависимости от ваших потребностей, вы можете захотеть сделать только часть CI, а не компакт-диск. А если ваша компания даже не использует CI, значит, что-то серьезно не так.

💡 Когда вы изучаете CICD, обратите внимание на:

  1. Передовой опыт CI. Интегрируйте линтинг, модульное тестирование и проверку обновлений безопасности в свой CI. Убедитесь, что окружение в CI соответствует окружению в prod! Запретить людям сливаться с хозяином. Запустите CI по их PR.
  2. Передовой опыт работы с компакт-дисками: обязательно изучите передовой опыт развертывания! Вы хотите закрепить версию продукта и просто автоматически развернуть ее в среде разработки с каждым слиянием, которое нужно освоить. Вы просто хотите YOLO и развертывать в продакшене с каждым слиянием, которое нужно освоить? Вы хотите, чтобы люди могли создавать развертывания вне своих филиалов? Вы хотите выполнять скользящие развертывания или сине-зеленые развертывания?

4. Датадог

Изучение Datadog или другой службы регистрации и мониторинга, такой как CloudWatch или Prometheus. После того, как ваше приложение будет запущено и запустится, вам понадобится куда-нибудь экспортировать журналы и отслеживать их. В Datadog есть много функций, таких как APM, Synthetics, Alerts, но не переусердствуйте!

💡 Когда вы изучаете Datadog, обратите внимание на:

  1. Управление журналами. Когда вы развертываете приложение, первое, что вам нужно сделать, это просмотреть журналы. Очевидно журналы отличные. Вы можете использовать их для отладки и создания мониторов. Например, вы можете отслеживать любые 500 кодов состояния, которые появляются в журналах nginx, чтобы предупреждать об ошибках в приложении. Узнайте, как искать в журналах по хосту, сервису и статусу. Также изучите изящные вещи, такие как сохранение представлений, чтобы упростить поиск в журналах.
  2. Мониторы и показатели. После импорта журналов на их основе можно создавать мониторы. Узнайте, как создавать мониторы для оповещения о сбоях (например, об ошибках в службе) или аномалиях (например, о повышении количества авторизованных кодов состояния 401) и о плохих проверках работоспособности (например, при ответе службы с кодом состояния, отличным от 200). Вы также можете отправлять пользовательские метрики в Datadog, а затем создавать на их основе мониторы.

5. Фляга

Часто вам придется развернуть быстрые API-интерфейсы для внутренних служб вашей компании. Полезным веб-фреймворком для изучения является Flask или что-то подобное, например Node.js. Обычно в DevOps, поскольку эти сервисы относительно легковесны по сравнению с тем, какой бы ни был основной сервис компании, их не нужно создавать с использованием языков с безопасной типизацией, таких как Java, или тяжелых фреймворков, таких как Spring. Но со скоростью разработки появляется и ответственность.

Flask довольно прост, но при разработке надежного приложения Flask, помимо всего лишь фреймворка, нужно обратить внимание на множество вещей:

💡 Когда вы изучаете эти веб-фреймворки, обратите внимание на:

  1. Базы данных / миграции баз данных. Если вашему приложению необходимо хранить данные, обратите внимание на передовые методы подключения к базам данных, определения моделей и выполнения миграции баз данных для потенциальных изменений схемы.
  2. Мониторинг и оповещение. Из-за легкости этих фреймворков мониторинг и ведение журнала становятся чрезвычайно важными, поскольку ошибки могут и будут легко возникать. Обязательно узнайте, как можно поднять 500 кодов статуса или исключений.
  3. Дизайн API: Возможно, этот вариант не слишком специфичен для Flask, но знание того, как устроены API, имеет решающее значение. В конечном итоге вам нужно будет создать конечные точки и выбрать между различными методами, такими как GET или POST. Принимая параметры, вам нужно знать, когда использовать параметр запроса или параметр пути. Узнайте, как сгруппировать конечные точки для вашей конкретной платформы. Flask содержит Blueprints, которые помогают упростить большие приложения и группировать похожие конечные точки вместе.

Еще кое-что, что нужно узнать, - это то, какие именно коды состояния возвращать. Неизбежно кто-то будет использовать ваш API, и неправильные коды статуса могут их расстроить. Хотя это больше связано с общими знаниями о разработке API, все же было бы хорошо знать, когда возвращать наиболее частые коды состояния:

  • внутренняя ошибка сервера 500)
  • 200 (ok!)
  • ошибка 400, неверный запрос)
  • 401 (неавторизованный)
  • 403 (запрещено)

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

Еще нужно иметь в виду управление конфигурацией. Каждому приложению, вероятно, потребуется какое-то управление конфигурациями, поскольку им нужно где-то хранить свои секреты или определять, какие конфигурации среда prod будет использовать по сравнению со средой dev. Если ваше приложение невелико, вам, вероятно, удастся обойтись легким управлением конфигурацией. Может быть, все, что вам нужно сделать, это поместить свои секреты в переменные среды и все! Однако, если вы подозреваете, что ваше приложение будет большим, вам нужно будет решить, хотите ли вы по-прежнему заниматься чем-то более сложным, например, помещать свои секреты в систему управления секретами.

6. Python

Изучение Python или другого языка сценариев будет иметь решающее значение для DevOps. Эти языки упрощают автоматизацию задач и создание микросервисов. В частности, Python универсален и полезен не только для DevOps, но и для науки о данных, машинного обучения, веб-разработки и многих других (на случай, если вы когда-нибудь захотите сделать карьеру!). С Python можно многому научиться, и если вы не знаете каких-либо языков программирования, лучше всего начать со знакомства с структурами данных, объектами и классами.

💡 Когда вы изучаете Python, обратите внимание на

  1. Типы. С динамическими языками вы потеряете понимание того, какие типы передаются. Что возвращается из этой функции? Сделайте все возможное, чтобы попытаться отслеживать, какие типы используются и где возвращаются. Используйте классы данных, TypedDicts, MyPy, схемы или даже простые комментарии. Если это неброский сценарий, комментариев может быть достаточно, поскольку чего-то вроде MyPy было бы излишне. Однако, если вы разрабатываете что-то большое, лучше всего начать с MyPy, иначе вы получите ошибку и начнете кричать на кого-то из-за того, что он не предоставил строки документации.
  2. Библиотеки и фреймворки. Лучше всего изучить библиотеку / фреймворк, которые связаны с тем, что вы делаете, чтобы не писать что-то, что уже существует, с нуля. В Python, вероятно, есть библиотека или функция для большинства вещей, которые обычно менее подвержены ошибкам. Пишете API? Изучите библиотеку запросов. Пишете API для Elasticsearch? Для этого API уже существует библиотека Python. Делаете кучу тяжелой математики? Попробуйте посмотреть, есть ли у панд для этого функция. Отстойно тратить много времени на написание функции для чего-то вроде вычисления скользящих средних по гигантскому набору данных, когда эта функция уже существует.
  3. Гибкость. Python - универсальный язык, и универсального решения не существует. Часто вы слышите, как люди хвалят достоинства шаблонов проектирования, но обычно вам не понадобятся такие вещи, как Singleton или Facade в Python, потому что вместо этого вы можете просто использовать модули. Вам неизбежно понадобятся некоторые классы, но функции - это первоклассный гражданин Python, что означает, что вам не нужно иметь класс для всего. Быть гибким! Иногда подходят шаблоны проектирования Java, которые Java-программист хочет использовать в Python. Иногда они слишком сложны для этого языка.

7. Докер / Контейнеры / Kubernetes

Извините, что я добавил так много всего в этот последний пункт! Но все они как бы связаны. Сначала я расскажу о докере / контейнерах. Контейнеры отличные! В противном случае вы можете использовать библиотеку, которая отлично работает на вашем Mac, но не работает в облаке. Все больше и больше компаний начинают использовать контейнеры, поскольку они позволяют создавать согласованные среды, а также более быстрое и простое развертывание. Если ваша компания использует Kubernetes, вы будете использовать контейнеры. Если ваша компания имеет дело с сервисами AWS, такими как AWS Batch, ECS и т. Д., Вы также будете использовать контейнеры.

💡 Когда вы изучаете Docker / Containers / Kubernetes, обратите внимание на:

  1. Когда не использовать контейнеры. Контейнеры сложны и могут потребовать много времени на запуск. Более того, с такими вещами, как сеть, тома и безопасность, сложнее справиться в контейнерах. Большинство людей хотят запихнуть все в контейнер, потому что это новая модная вещь, но вы должны подумать о том, будет ли достаточно развертывания на что-то более простое. Например, если ваше приложение небольшое, может быть достаточно просто развертывания через лямбда с zip-файлом, содержащим код. Если ваше приложение слишком велико для лямбда-выражения, возможно, достаточно ElasticBeanstalk или Google App Engine.
  2. Сеть / безопасность: контейнеры - это еще один уровень сети и безопасности, о котором следует подумать. У хоста будет определенный набор конфигураций сети / безопасности, которых может не быть у контейнера, и наоборот.
  3. Изоляция. Это больше связано со службами оркестровки контейнеров, такими как Kubernetes. Поскольку группа пользователей может совместно использовать один и тот же кластер Kubernetes, вам необходимо научиться эффективно изолировать ресурсы для каждой службы. Вам нужно будет знать о пространствах имен, изоляции данных и изоляции на сетевом уровне.

Хороший! Вы добрались до конца. Надеюсь, вы нашли это полезным. Иногда действительно интересно и приятно заниматься DevOps, и, к тому же, вы можете звучать круто, говоря о своем кластере Kubernetes.