Як використання Ansible полегшує життя Ops/DevOps інженерам

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Я працюю DevOps-інженером вже другий рік, а до цього два роки працював системним адміністратором. Тоді мені довелося вручну розгортати проєкт на чотири продакшн-сервери, кожен із унікальною конфігурацією.

Це виявилося складним і тривалим процесом, де навіть найменша помилка могла викликати проблеми. Саме тоді я познайомився з концепцією «інфраструктура як код» і впровадив Ansible, що дозволило значно спростити роботу і зосередитися на важливіших завданнях.

Як працює Ansible

Ansible — це інструмент для автоматизації, який дає змогу спрощувати управління IT-інфраструктурою. Він допомагає автоматизувати процеси налаштування систем, розгортання застосунків, управління конфігурацією та виконання рутинних завдань. Однією з головних переваг є його простота та безагентна архітектура, що робить його легким у впровадженні та використанні.

Він використовує просту мову YAML для опису завдань у так званих «плейбуках», що дає змогу чітко та зрозуміло визначати дії, які потрібно отримати на віддалених системах.

Ключові елементи Ansible

  • Control Node. Це центральний сервер або звичайний laptop, на якому встановлений Ansible і з котрого виконується управління іншими серверами.
  • Інвентаризаційний файл (Inventory file). Список серверів, якими Ansible керує. Він може бути статичним файлом з IP-адресами або динамічним, що змінюється в реальному часі.
  • Playbooks. YAML-файли, що містять серії завдань, які потрібно виконати на віддалених серверах. Завдання можуть бути такі: інсталяція програмного забезпечення, управління конфігурацією, налаштування сервісів тощо.
  • Modules. Модулі — це виконувані блоки, які Ansible використовує для виконання конкретних завдань, як-то копіювання файлів, керування пакетами або налаштування мережевих інтерфейсів.
  • Roles. Ролі дають змогу організувати плейбуки у багаторазові та структуровані блоки, що полегшує управління складними конфігураціями та підвищує масштабованість. Вони містять завдання, хендлери, темплейти та інші компоненти, що спрощує їх повторне використання та підтримку.
  • З’єднання. Ansible з’єднується з віддаленими серверами за допомогою SSH або WinRM для Windows і виконує завдання без необхідності встановлення агентів на віддалених системах.


Control Node знаходиться в центрі, забезпечуючи централізоване управління та автоматизацію завдань на віддалених системах. Ролі в Ansible допомагають організувати ці завдання ефективно, полегшуючи автоматизацію навіть складних конфігурацій.

Ця проста архітектура дає змогу ефективно автоматизувати управління великою кількістю серверів, зберігаючи всі налаштування та задачі централізовано в репозиторії на GitLab/GitHub, а використання ролей робить цей процес ще більш гнучким та масштабованим.

Перше використання Ansible

Перед тим як створити свій перший плейбук, а згодом і ролі, я створив новий приватний репозиторій на GitLab. Визначив інвентаризаційний файл, у якому описав сервери, на яких потрібно було виконати конфігурацію. Використовуючи документацію, я виділив їх в окрему підгрупу [devops].

Першим кроком замість команди ping використано команду, яка перевіряє доступність серверів і показує відповідь «pong», якщо сервер доступний. Цей метод має додаткову перевагу: якщо ICMP відключений і ping не проходить, ця команда все ще може перевіряти доступність сервера, що робить її більш надійною у випадках, коли ICMP-блокування ускладнює перевірку зв’язку.

Після перевірки доступності серверів і вивчення документації було розроблено перший плейбук, здатний виконувати завдання на серверах з різними операційними системами. Для ілюстрації подібного підходу наступний плейбук орієнтований на збір інформації про модель процесора та кількість ядер виключно на серверах з операційною системою Ubuntu.

Після виконання завдання продовжив вивчати Ansible і дійшов до ролей. Ролі — це зручний спосіб структурувати завдання, роблячи їх повторно використовуваними та легкими для управління. Вони допомагають уникнути дублювання коду, організувати змінні та файли в чітку структуру, що значно спрощує автоматизацію й підтримку.

Порівняння архітектур проєктів Ansible

У процесі роботи з Ansible існують різні підходи до організації проєктів, кожен з яких має свої переваги та недоліки. Зокрема, можна виділити два основні варіанти архітектури: монолітний підхід та поділ на окремі модулі (ролі). На зображенні схематично окреслено ці дві архітектури, які ми детально розглянемо.



Монолітний підхід

Переваги

Легка підтримка. Всі конфігурації знаходяться в одному місці.

Економія ресурсів. Менше часу витрачається на налаштування, особливо на початкових етапах проєкту.

Мобільність. Зручний для невеликих проєктів або середовищ.

Недоліки

Нагромадженість. З часом проєкт може стати складним і важким для управління.

Важке масштабування. Оскільки всі конфігурації зосереджені в одному репозиторії.

Модульний підхід:

Переваги

Легка масштабується, оскільки кожна роль відповідає за конкретну частину конфігурації.

Полегшує повторне використання ролей між різними проєктами.

Забезпечує більшу гнучкість у керуванні конфігураціями, дає змогу адаптувати налаштування для різних середовищ.

Недоліки

Початкове налаштування може бути складнішим і займати більше часу.

Вимагає більшої уваги до структури проєкту, щоб забезпечити зрозумілу та логічну організацію ролей.

Може виникнути необхідність в управлінні залежностями між ролями, що збільшує складність проєкту.

Приклад використання Ansible

Завдяки простоті та гнучкості Ansible, DevOps-інженери можуть швидко і надійно розгортати необхідні сервіси, мінімізуючи ручну працю та знижуючи ризики допущення помилок.

На схемі показаний процес автоматизованого додавання нової конфігурації для веб-серверу з використанням Ansible. Далі наведу опис дій.

Додавання конфігурації

  • DevOps-інженер створює новий конфігураційний файл, наприклад, devops-doc_com_ua.conf, для додавання нового домену до веб-сервера в локальній мережі.

Пуш до GitLab

  • Після створення файлу конфігурації, інженер пушить його до репозиторію в GitLab.
  • На цьому дії інженера закінчені.

Автоматичний тригер CI/CD

  • Після того як новий конфігураційний файл доданий до ролі, а зміни запушені в репозиторій, це автоматично ініціює тригер в основному проєкті servers. GitLab CI/CD використовує цей тригер для запуску пайплайну, що займається розгортанням конфігурацій на серверах.

Запуск пайплайну

  • Тригер активує пайплайн, який виконує кілька важливих кроків.
  • Спочатку він завантажує основний проєкт із конфігураціями серверів (servers), а також проєкт з ролями Ansible (roles).
  • Далі пайплайн переходить до виконання плейбука Ansible, наприклад, nginx.yml, який містить нову конфігурацію.

Розгортання та перевірка

  • Перед застосуванням нової конфігурації пайплайн виконує автоматизовані перевірки, щоб переконатися в її коректності. Це може містити тестування на відповідність синтаксису, перевірку доступності необхідних ресурсів та інші важливі перевірки. Якщо всі перевірки пройшли успішно, Ansible автоматично розгортає нову конфігурацію на цільовому сервері.

Висновки про Ansible

Ansible як засіб шаблонізації серверів є відмінним вибором, особливо в поєднанні з такими інструментами DevOps, як GitLab-ci, Jenkins та іншими. Він забезпечує простий і зрозумілий підхід до автоматизації налаштування серверів, даючи змогу швидко й ефективно впроваджувати зміни в інфраструктурі. Завдяки інтеграції з CI/CD інструментами, Ansible допомагає автоматизувати процеси розгортання та забезпечує консистентність конфігурацій.

Однак, якщо мова йде про виділення і управління ресурсами, такими як створення віртуальних машин, мережевих конфігурацій або керування хмарними середовищами, існують інші більш спеціалізовані інструменти, як-от Terraform. Хоча Ansible також надає можливість роботи з такими завданнями.

Плюси

Простота використання. Ansible не потребує спеціальних агентів на серверах, використовує SSH для підключення, що спрощує налаштування та управління.

Масштабованість. Легко масштабується на великі інфраструктури з можливістю одночасного управління сотнями серверів.

Зрозумілий синтаксис. Використання YAML-файлів для опису плейбуків робить конфігурації зрозумілими і легкими в читанні.

Мінуси

Обмежена швидкість. Під час роботи з великою кількістю серверів, виконання завдань послідовно може бути повільнішим у порівнянні з інструментами, які працюють паралельно.

Залежність від SSH. Використання SSH як основного методу підключення може викликати проблеми з продуктивністю і безпекою, особливо на великих інфраструктурах.

Посилання

💬 linkedin: Dmitry Shvydenko

💬 github: CrudelisDeus

❤️ linkedin: Valeriia Sokyrko, дякую за допомогу в створені статті!

👍ПодобаєтьсяСподобалось9
До обраногоВ обраному4
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

От тільки Ansible — це здебільшлго configuration management tool, хоча і може трохи в IaC.

Я б сказал что ansible в целом легче любому жизнь сделает, а не только девопсу. Можно роли расписать как конструктор и собирать/развертывать свои проекты на новом или том же сервере просто одной командой. Кто-то скажет, что достаточно run.sh, а я скажу, что формирование env для теста и прода, разных паролей/конфигов для бд и немного разных кронов, etc с шеллом не так продуктивно будет.
Конечно в идеале каждый проект внутри себя должен иметь одинаковую структуру файлов для развертывания, например в корне Dockerfile чтобы вызвать сборку нужных либ и тд

Ansible без Mitogen — гроші на вітер власний час на очікування

Дякую за статтю. Маю невелике питання. Намагаюсь перенести свою апку в хмару. chatgpt накидав такий сетап:

Terraform provisions the infrastructure, including AWS EKS and ECR.

Ansible installs ArgoCD, Helm, and Kubernetes External Secrets.

GitHub Actions automates Docker image building and deployment.

Kubernetes External Secrets fetches secrets from AWS Secrets Manager.

ArgoCD manages the GitOps-based continuous delivery model.

Що скажете?

Звучить як повний стек DevOps.
На мою думку, для розробника, якому цікаво познайомитися з хмарними рішеннями, достатньо самостійно створити сервер EC2 (AWS) і скористатися GitHub Actions.

Що стосується Terraform та iншого, воно підходить більше для pet-проєктів тільки тим DevOps-інженерам, які вчаться впроваджувати повноцінні рішення.

Для розробника це марна трата часу, якщо ти не плануєш у майбутньому спробувати себе в ролі DevOps-інженера)

Ansible installs ArgoCD, Helm, and Kubernetes External Secrets.

Это лишний шаг. Ансибл в таком сетапе вообще не нужен. Арго ставится один раз и менеджит сам себя + всё остальное.

>

Ansible installs ArgoCD, Helm, and Kubernetes External Secrets.

галюни у чатіка.
Ansible взагалі тут вам не потрібний. Helm ставити також не треба. використовуючи helm provider в terraform ви можете арго, exteral secrets and many more всунути одразу в кластер.

Але краще не треба, бо хелм провейдер трохи гівно. Краще один раз поставити argocd руками і менеджить кубернетес апки з його допомогою. Включно з самим аргосд, як це не дивно.

Підписатись на коментарі