Практический опыт автоматизированной эксплуатации и технического обслуживания некоторых небольших групп

задняя часть Эксплуатация и техническое обслуживание

Практический опыт автоматизированной эксплуатации и технического обслуживания некоторых небольших групп

Примечание. Для этой статьи читатели должны иметь некоторые знания об Ansible и Jenkins.

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

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

image

Команда автора, состоящая из трех с половиной разработчиков, обслуживает десятки облачных машин и развертывает более десяти приложений, 90% из которых являются устаревшими системами. Компиляция и упаковка прикладной системы в основном выполняется на собственном компьютере программиста. Управление ветками также разработано в ветке dev, после прохождения теста она объединяется с веткой master. Конфигурацию приложения в производственной среде можно узнать, только войдя в систему на конкретной машине, не говоря уже о центре конфигурации и управлении версиями конфигурации.

Кстати, нет даже базового машинного мониторинга.

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

Не говорите, сначала на мониторинге и оповещения

Расстановка приоритетов, мониторинг и оповещение — это то, что, по моему мнению, следует делать с самого начала, даже если развитие бизнеса замедляется. Только когда вы знаете текущую ситуацию, вы можете планировать следующий шаг.

На рынке сегодня много систем мониторинга: Zabbix, Open-Falcon, Prometheus. В итоге автор выбрал Прометея. так как:

  1. он находится в режиме вытягивания
  2. Для настройки удобно использовать текстовый режим, что способствует управлению версиями конфигурации.
  3. Плагинов слишком много. То, что вы хотите отслеживать, будет в основном готово.
  4. Вышеупомянутые три, я в основном должен заново учиться, почему бы мне не изучить рекомендованную книгу Google SRE?

Как мы уже упоминали ранее, людей меньше, а машин больше, поэтому процесс установки Prometheus также должен быть автоматизирован и версионирован. Автор использует реализацию Ansible + Git. Окончательный вид выглядит следующим образом:

prometheus

Вот краткое введение:

  1. Prometheus Server отвечает за мониторинг сбора и хранения данных.
  2. Менеджер оповещений Prometheus отвечает за оповещения в соответствии с правилами оповещений и может интегрировать множество каналов оповещений.
  3. node-exporterЕго роль — считывать метрики с машины и предоставлять доступ к http-сервису, из которого Prometheus собирает метрики мониторинга. Конечно, у Prometheus официально есть множество экспортеров.

Одним из преимуществ использования Ansible в качестве инструмента развертывания является то, что слишком много готовых ролей, при установке Prometheus я использую готовые:prometheus-ansble

После того, как у нас есть данные мониторинга, мы можем визуализировать данные, Grafana и Prometheus очень хорошо интегрируются, поэтому мы развертываем Grafana:

image.png

Просмотр данных, собранных nodex-exporter в FIG Grafana эффект, вероятно, выглядит следующим образом:image.png

Однако мы не можем смотреть на экран 24 часа, чтобы увидеть, не превысила ли загрузка процессора, верно? В это время будет сообщено о тревоге.Promehtues по умолчанию интегрирует N нескольких каналов тревоги. Жаль, что нет встроенного DingTalk. Но это не имеет значения.Добрые студенты открыли исходный код компонентов Dingding для интеграции сигналов тревоги Prometheus:prometheus-webhook-dingtalk. Затем мы также получили сигнал тревоги:集成告警

После выполнения вышеуказанных работ полка нашего базового мониторинга завершена. Он готов для мониторинга более высокого уровня, такого как мониторинг Redis и мониторинг JVM на более позднем этапе.

Управление версиями конфигурации должно начинаться с куклы

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

О том, как использовать Anisible Management Configuration, вы можете обратиться к этой статье:How to Manage Multistage Environments with Ansible. Мы используем это, чтобы организовать переменную среды.

├── environments/         # Parent directory for our environment-specific directories
│   │
│   ├── dev/              # Contains all files specific to the dev environment
│   │   ├── group_vars/   # dev specific group_vars files
│   │   │   ├── all
│   │   │   ├── db
│   │   │   └── web
│   │   └── hosts         # Contains only the hosts in the dev environment
│   │
│   ├── prod/             # Contains all files specific to the prod environment
│   │   ├── group_vars/   # prod specific group_vars files
│   │   │   ├── all
│   │   │   ├── db
│   │   │   └── web
│   │   └── hosts         # Contains only the hosts in the prod environment
│   │
│   └── stage/            # Contains all files specific to the stage environment
│       ├── group_vars/   # stage specific group_vars files
│       │   ├── all
│       │   ├── db
│       │   └── web
│       └── hosts         # Contains only the hosts in the stage environment
│

На данном этапе все наши конфигурации хранятся в тексте, и в будущем будет очень удобно перейти на использование Consul в качестве центра конфигурации, т.к. версии выше Ansible 2.0 имеют нативно интегрированный consule:consul_module

Tips:Переменные конфигурации Ansible иерархичны, что дает нам большую гибкость в управлении конфигурацией.

Дженкинсификация: ручная упаковка для Дженкинса

Мы собираемся передать всю упаковку проекта Дженкинсу. Конечно, в реальности мы сначала ставим какие-то проекты на Jenkins для упаковки, и постепенно ставим проекты на Jenkins.

Сначала у нас есть Дженкинс. Также есть готовые Ansible-скрипты для сборки Jenkins:ansible-role-jenkins. Attention, you see online are mostly Jenkins article tells you need to manually install plug-ins, and we are using this ansible-role-jenkins achieved automatically install the plugin, you just need to add a configuration variable jenkins_plugins on it, official examples are следующее:

---
- hosts: all
  vars:
    jenkins_plugins:
      - blueocean
      - ghprb
      - greenballs
      - workflow-aggregator
    jenkins_plugin_timeout: 120

  pre_tasks:
    - include_tasks: java-8.yml

  roles:
    - geerlingguy.java
    - ansible-role-jenkins

После настройки Jenkins, настало время интегрировать GitLab. У нас уже есть gitlab, поэтому нам не нужно восстановить. Как интегрировать не подробно, есть много статей в Интернете.

В итоге Jenkins строится так:jenkinsЧто касается метода подключения между мастером Jenkins и агентом Jenkins, то из-за различных сетевых сред в Интернете существует множество способов, и каждый может выбрать подходящий метод.

Хорошо, теперь нам нужно сообщить Дженкинсу, как компилировать и упаковывать наш бизнес-код. Есть два способа:

  1. настройки интерфейса
  2. Использование Jenkinsfile: текстовый файл, похожий на Dockerfile, который подробно описан:Using a Jenkinsfile

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

Дженкинсфайл выглядит так:

pipeline {
    agent any
    stages {
        stage('Build') {
            steps {
                sh './gradlew clean build'
                archiveArtifacts artifacts: '**/target/*.jar', fingerprint: true
            }
        }
    }
}

Так где же файл Дженкинса? Соедините это с бизнес-кодом, вот так, каждый проект управляет своим Jenkinsfile:

jenkinsfile

На этом этапе мы можем создать конвейерную работу на Jenkins:

Что касается управления ветками, то у нас мало людей, поэтому рекомендуется все проекты разрабатывать и выпускать в основной ветке.

Позвольте Дженкинсу помочь нам выполнить Ansible

Раньше мы все выполняли Ansible на компьютере программиста, теперь мы собираемся передать эту работу Дженкинсу. Конкретные операции:

  1. Установить в ДженкинсAnsible-плагин
  2. Выполнить в Jenkinsfile
    withCredentials([sshUserPrivateKey(keyFileVariable:"deploy_private",credentialsId:"deploy"),file(credentialsId: 'vault_password', variable: 'vault_password')]) {
             ansiblePlaybook vaultCredentialsId: 'vault_password', inventory: "environments/prod", playbook: "playbook.yaml",
             extraVars:[
               ansible_ssh_private_key_file: [value: "${deploy_private}", hidden: true],
               build_number: [value: "${params.build_number}", hidden: false]
             ]
}

    Здесь нужно пояснить:

  3. ansiblePlaybookЭто синтаксис конвейера, предоставляемый подключаемым модулем Jenkins, аналогичный ручному выполнению:ansible-playbook.
  4. withCredentialsдаCredentials BindingСинтаксис плагина для ссылки на конфиденциальную информацию, такую ​​как ключ ssh и пароль Ansible Vault, необходимые для запуска Ansible.
  5. Некоторые чувствительные переменные конфигурации, которые мы используемAnsible VaultТехническое шифрование.

Куда должны деваться скрипты Ansible?

Мы уже знаем, что каждый проект отвечает за свою автоматическую сборку, поэтому Jenkinsfile помещается в отдельный проект. А как насчет развертывания проекта? По той же причине мы считаем, что каждый проект должен отвечать сам за себя, поэтому каждый из наших проектов, который будет развернут, будет иметьansibleКаталог для хранения скриптов Ansible. Что-то вроде этого:ansible

Но как его использовать? Мы заархивируем каталог Ansible на этапе упаковки. При фактическом развертывании разархивируйте и запустите плейбук внутри.

Быстро создавайте сценарии Ansible и Jenkinsfiles для всех проектов

Выше мы Jenkinsified и Ansibleized проект, но у нас есть еще много проектов, которые должны делать то же самое. Учитывая, что это физическая работа, и в дальнейшем мы будем часто ею заниматься, я решил использоватьcookiecutterТехнология автоматически генерирует сценарии Jenkinsfile и Ansible для создания такого проекта:cookiecutter

резюме

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

  1. базовый мониторинг
  2. на Гитлабе
  3. На Jenkins и интегрировать Gitlab
  4. Используйте Jenkins Автоматический компилятор Пакет
  5. Выполнить Ansible с Дженкинсом

Это всего лишь полка, и на основе этой «полки» мы можем развиваться до высокоуровневой архитектуры этих больших заводов. Например:

  • Построение CMDB: Мы используемansible-cmdbАвтоматически генерировать текущее состояние всех машин по данным инвентаризации
  • Управление выпуском: каждый этап выпуска можно настроить в Jenkins. Методы выпуска, такие как сине-зеленый выпуск, могут быть реализованы путем изменения сценариев Ansible и Inventory.
  • Автоматическое расширение и сжатие: путем настройки правил оповещения Prometheus и вызова соответствующего веб-перехватчика этого можно добиться.
  • ChatOps: Чаты в действии

Выше приведены некоторые из практик автора по автоматизированной эксплуатации и обслуживанию. Еще в пути. Надеюсь на общение с вами.

End

Платите за свой урожай
Категории