Как работает TLS Handshake

by moiseevrus 17.05.2023

written by moiseevrus

TLS (Transport Layer Security) Handshake (или SSL Handshake) – это процесс установки защищенного соединения между клиентом и сервером с использованием протокола TLS/SSL. Он включает в себя обмен информацией и установку параметров для безопасной коммуникации.

Вот основные шаги процесса TLS Handshake:

Приветствие (Hello): Клиент отправляет приветственное сообщение серверу, включающее версию протокола TLS, список поддерживаемых шифров, случайное число (ClientHello). Также клиент может указать список поддерживаемых методов сжатия данных.
Приветствие-ответ (Hello-ACK): Сервер отвечает клиенту приветственным сообщением (ServerHello), в котором указывает выбранную версию протокола TLS, метод шифрования и случайное число. Сервер также отправляет свой сертификат (если требуется) и запрос на аутентификацию клиента (если необходимо).
Аутентификация сервера: Клиент проверяет сертификат сервера, чтобы убедиться в его подлинности и правильности. Клиент также может проверять цепочку сертификатов, чтобы удостовериться, что сертификат сервера был выдан надежным удостоверяющим центром.
Генерация общего секрета: Клиент и сервер генерируют общий секретный ключ, который будет использоваться для шифрования и расшифровки данных во время сеанса. Обмен этим секретом происходит с использованием криптографического протокола Diffie-Hellman или его вариантов.
Переключение на защищенное соединение: Клиент и сервер согласовывают параметры шифрования, метод сжатия данных и другие настройки безопасности. Затем они переключаются на защищенное соединение, используя общий секретный ключ. Это означает, что все данные, передаваемые между клиентом и сервером, будут шифроваться и расшифровываться.
Завершение Handshake: Клиент и сервер обмениваются сообщениями, подтверждающими успешное завершение Handshake. Теперь они могут начать безопасную коммуникацию, используя установленное защищенное соединение.

TLS Handshake обеспечивает аутентификацию, конфиденциальность и целостность данных во время коммуникации между клиентом и сервером. Он выполняется в начале каждого сеанса и устанавливает безопасные параметры для обмена информацией.

17.05.2023 0 comment

Бизнес в итернете

Как работает утилита Tracerout

by moiseevrus 17.05.2023

written by moiseevrus

Traceroute (также известный как tracert в некоторых операционных системах) – это утилита сетевой диагностики, которая позволяет отслеживать путь, по которому пакеты данных отправляются от вашего компьютера до конечного назначения в сети. Она используется для определения проблем в сети, выявления задержек и анализа маршрутов.

Вот как работает утилита Traceroute:

Отправка пакетов с TTL (Time to Live): Traceroute отправляет пакеты данных к конечному пункту назначения с начальным значением TTL равным 1. TTL представляет собой счетчик, который ограничивает время жизни пакета в сети. Когда пакет проходит через маршрутизатор, значение TTL уменьшается на 1.
Получение ICMP Time Exceeded: Когда пакет достигает маршрутизатора с TTL равным 0, маршрутизатор отбрасывает пакет и отправляет обратно ICMP Time Exceeded сообщение обратно отправителю. Это сообщение указывает на то, что TTL пакета истек и он был отброшен.
Запись адреса маршрутизатора: Traceroute записывает адрес маршрутизатора, от которого получено ICMP Time Exceeded сообщение. Это позволяет отслеживать промежуточные узлы (маршрутизаторы) на пути до конечного пункта назначения.
Увеличение значения TTL: Traceroute повторяет процесс с увеличением значения TTL на 1 и отправляет следующий пакет. Таким образом, пакеты проходят через все большее количество маршрутизаторов на пути до конечного пункта назначения.
Определение времени задержки: Traceroute также записывает время, затраченное на прохождение пакета через каждый маршрутизатор. Это позволяет оценить время задержки (ping) между вашим компьютером и каждым маршрутизатором на пути.
Завершение и анализ результатов: Traceroute продолжает отправлять пакеты с увеличенным TTL до тех пор, пока не достигнет конечного пункта назначения или пока не будет достигнуто максимальное количество прыжков (hops). После завершения утилиты выводит результаты, включающие адреса маршрутизаторов, время задержки и прочую информацию.

Traceroute предоставляет информацию о промежуточных узлах (маршрутизаторах) и времени задержки на каждом участке пути до конечного назначения. Это полезный инструмент для диагностики сетевых проблем, определения узких мест и анализа маршрутов сетевого трафика.

17.05.2023 0 comment

Бизнес в итернете

Что такое OSPF протакол

by moiseevrus 17.05.2023

written by moiseevrus

OSPF (Open Shortest Path First) – это протокол маршрутизации в сетях TCP/IP, который используется для определения наименьшего стоимостного пути и обмена информацией о маршрутах между маршрутизаторами. OSPF является протоколом внутренней маршрутизации (Interior Gateway Protocol – IGP) и широко применяется в больших сетях, таких как корпоративные сети или Интернет-провайдеры.

Вот основные особенности и принципы работы OSPF:

Соседство (Neighborship): Маршрутизаторы, работающие с OSPF, устанавливают соседство друг с другом, чтобы обмениваться информацией о маршрутах. Соседство OSPF устанавливается на основе обмена Hello-пакетами между соседними маршрутизаторами.
Алгоритм SPF (Shortest Path First): OSPF использует алгоритм SPF для определения наименьшего стоимостного пути (кратчайшего пути) до целевой сети. Он учитывает стоимость связей между маршрутизаторами (основанную на пропускной способности или метрике) и строит дерево кратчайших путей для всех сетей в сетевой топологии.
Обновление маршрутной информации: OSPF маршрутизаторы обмениваются сообщениями Link State Advertisement (LSA) для обновления информации о маршрутах. Каждый маршрутизатор создает базу данных LSDB (Link State Database), содержащую информацию о сетевой топологии и доступных маршрутах.
Расчет маршрутов: На основе информации в LSDB каждый маршрутизатор OSPF вычисляет наименьшие стоимостные пути с использованием алгоритма SPF. Расчет выполняется локально на каждом маршрутизаторе, и каждый маршрутизатор знает только о путях до своих соседних сетей.
Обнаружение изменений в топологии: OSPF обладает механизмом обнаружения изменений в топологии сети. Когда происходят изменения, например, отказ маршрутизатора или изменение стоимости связи, OSPF обновляет информацию о маршрутах и пересчитывает кратчайшие пути.
Автономные области (Areas): OSPF позволяет разделить сеть на несколько автономных областей (areas). Каждая область имеет свою локальную базу данных и может выполнять SPF-расчеты независимо от других областей. Это помогает уменьшить объем обмена сообщениями и улучшить производительность сети.

OSPF является мощным и гибким протоколом маршрутизации, который обеспечивает эффективное использование ресурсов сети и быструю сходимость маршрутов. Он поддерживает различные типы сетей, включая Ethernet, Frame Relay, ATM и другие.

17.05.2023 0 comment

Бизнес в итернете

Как настроить метрики в Grafana

by moiseevrus 17.05.2023

written by moiseevrus

Grafana – это популярный инструмент визуализации данных и построения дашбордов. Он интегрируется с различными источниками данных, включая Prometheus. Вот несколько примеров настройки метрик в Grafana:

Создание источника данных:
- Откройте панель администратора Grafana и перейдите в раздел “Configuration”.
- В разделе “Data Sources” нажмите на кнопку “Add data source”.
- Выберите тип источника данных, например, “Prometheus”.
- Укажите URL Prometheus и другие настройки, такие как авторизация, если она требуется.
- Сохраните настройки источника данных.
Создание дашборда:
- Вернитесь на главную панель Grafana и выберите “Create” -> “Dashboard”.
- В разделе “Panel Data Source” выберите ранее созданный источник данных Prometheus.
- Нажмите на кнопку “Add Query” для добавления нового запроса к метрикам.
- Введите запрос Prometheus для получения нужных метрик. Например, http_requests_total или cpu_usage.
- Настройте параметры запроса, такие как временной диапазон, интервал обновления и агрегацию.
- Повторите процесс для добавления других метрик или панелей на дашборд.
- Когда закончите, сохраните дашборд.
Настройка панелей:
- Нажмите на панель дашборда, чтобы открыть редактор панели.
- В редакторе панели вы можете настроить внешний вид, тип графика, цвета, шрифты и другие параметры.
- Также вы можете применять функции и операции к метрикам, чтобы создать более сложные выражения или агрегации данных.
- Экспериментируйте с различными настройками и параметрами, чтобы достичь желаемого визуального представления метрик.
Сохранение и публикация дашборда:
- Когда настройка панелей завершена, сохраните дашборд.
- Вы можете предоставить доступ к дашборду другим пользователям, настроив права доступа и шаринг определенных панелей или всего дашборда.

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

17.05.2023 0 comment

Devops практики

Cинхронизация между горутинами в языке Go

by moiseevrus 14.05.2023

written by moiseevrus

В Golang горутины (goroutines) являются легковесными потоками, которые позволяют легко создавать параллельные процессы в вашем коде. Однако, при использовании горутин возникают проблемы синхронизации, когда несколько горутин должны взаимодействовать между собой, чтобы выполнить определенную задачу. Для решения этих проблем синхронизации в Golang предоставляются следующие механизмы:

Каналы (Channels) – это простой механизм передачи данных между горутинами. Они позволяют одной горутине отправлять данные в канал, а другой горутине получать данные из канала. Каналы могут быть синхронными и асинхронными, и обычно используются для координации и синхронизации между горутинами.
Мьютексы (Mutex) – это механизм, который позволяет блокировать доступ к общим данным из разных горутин. Когда горутина хочет получить доступ к общим данным, она должна сначала захватить мьютекс, чтобы заблокировать другие горутины от доступа к этим данным. После того, как горутина закончила работу с общими данными, она должна освободить мьютекс, чтобы другие горутины могли получить к ним доступ.
WaitGroup – это механизм, который позволяет ждать выполнения нескольких горутин перед продолжением работы. WaitGroup содержит счетчик, который увеличивается каждый раз, когда горутина начинает работу, и уменьшается каждый раз, когда горутина завершает работу. Когда счетчик достигает нуля, WaitGroup сообщает, что все горутины завершили работу.
Select – это механизм, который позволяет выбирать из нескольких операций ввода-вывода, которые могут быть выполнены в данный момент. Он используется, когда несколько горутин ожидают на разных каналах и нужно выбрать тот, который первым будет доступен.

Рассмотрим пример использования select для чтения из двух каналов, чтобы увидеть, как он работает:

go

package main

import (
“fmt”
“time”
)

func main() {
ch1 := make(chan string)
ch2 := make(chan string)

go func() {
time.Sleep(2 * time.Second)
ch1 <- “Сообщение из канала 1”
}()

go func() {
time.Sleep(3 * time.Second)
ch2 <- “Сообщение из канала 2”
}()

for i := 0; i < 2; i++ {
select {
case msg1 := <-ch1:
fmt.Println(msg1)
case msg2 := <-ch2:
fmt.Println(msg2)
}
}
}

В этом примере мы создаем два канала ch1 и ch2, и запускаем две горутины, каждая из которых отправляет сообщение в свой канал через определенное время.

Затем мы используем оператор select, чтобы выбрать первый готовый канал и выполнить соответствующую операцию. В цикле for мы повторяем этот процесс дважды, чтобы получить оба сообщения.

Когда первая горутина отправляет сообщение в канал ch1, оператор select выбирает первый кейс, и мы выводим сообщение из канала ch1. Когда вторая горутина отправляет сообщение в канал ch2, оператор select выбирает второй кейс, и мы выводим сообщение из канала ch2.

Программа завершается после получения обоих сообщений. Если бы мы использовали блокирующее ожидание на каждом канале по отдельности, то мы должны были бы ждать, когда первый канал вернет результат, прежде чем продолжить ожидание на втором канале. С использованием оператора select мы можем ожидать обоих каналов одновременно и выбирать первый готовый результат.
Контексты (Context) – это механизм, который позволяет отменять выполнение горутин и передавать значения и сроки ожидания между горутинами.
Рассмотрим несколько примеров использования Context в Go:
1. Отмена операции
go

package main

import (
“context”
“fmt”
“time”
)

func main() {
ctx, cancel := context.WithCancel(context.Background())

go func() {
time.Sleep(5 * time.Second)
cancel()
}()

select {
case <-time.After(10 * time.Second):
fmt.Println(“Завершено успешно”)
case <-ctx.Done():
fmt.Println(“Отменено:”, ctx.Err())
}
}

В этом примере мы создаем контекст ctx и функцию cancel, которую можно использовать для отмены операции. Затем мы запускаем горутину, которая через 5 секунд вызывает функцию cancel().

Мы используем оператор select, чтобы ожидать результат операции. Если операция завершится успешно, мы выводим “Завершено успешно”. Если операция будет отменена, мы выводим “Отменено” и ошибку, полученную из ctx.Err().
1. Ограничение времени выполнения
go

package main

import (
“context”
“fmt”
“time”
)

func main() {
ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second)
defer cancel()

select {
case <-time.After(5 * time.Second):
fmt.Println(“Завершено успешно”)
case <-ctx.Done():
fmt.Println(“Отменено:”, ctx.Err())
}
}

В этом примере мы используем контекст ctx с временным ограничением выполнения в 3 секунды. Мы используем defer cancel() для того, чтобы контекст автоматически отменялся после выполнения программы.

Мы также используем оператор select для ожидания результата. Если операция завершится успешно, мы выводим “Завершено успешно”. Если операция будет отменена из-за истечения времени, мы выводим “Отменено” и ошибку, полученную из ctx.Err().
1. Передача значения через контекст
go

package main

import (
“context”
“fmt”
)

func main() {
ctx := context.WithValue(context.Background(), “ключ”, “значение”)
value := ctx.Value(“ключ”)
fmt.Println(value)
}

В этом примере мы используем контекст ctx для передачи значения “значение” по ключу “ключ”. Затем мы используем ctx.Value("ключ") для получения значения по ключу.

14.05.2023 0 comment

Devops практики

Лучшие практики Ansible: часть 1

by moiseevrus 17.12.2022

written by moiseevrus

Существует множество инструментов DevOps. Выбрать человека для работы не всегда просто. Используя его эффективно с самого начала, тем более.

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

Этот пост и следующий стремятся ответить на вопросы: «Когда я должен выбрать Ansible?» и «Как эффективно использовать Ansible?». Возможно также: «Почему Норвегия фальшивая?».

Поиск в Google: «Инженер DevOps». Возможно, Вы имели в виду: "инженер файлов YAML"

Что такое Анзибл?

Ansible — это инструмент автоматизации, используемый для управления конфигурацией и оркестровки инфраструктуры, систем и приложений.

Он начал свою жизнь как проект одного человека. Затем была расширена до компании и теперь спонсируется RedHat. Поддерживаемый сообществом открытого исходного кода, он является зрелым и широко используется.

Ansible, как и его известные товарищи: Chef , Puppet и SaltStack , используется для описания желаемого состояния системы в виде кода, что в данном случае означает YAML с вкраплениями шаблонов Jinja2 сверху. Все перечисленные инструменты стремятся к идемпотентности, что вкратце означает, что они вносят изменения только тогда, когда это необходимо. Есть некоторая разница в том, достигается ли это декларативно или императивно, но результат один и тот же.

Он имеет безагентную архитектуру, поэтому начать работу с ним несложно. Никаких зависимостей, кроме Python, для обработки управляемых хостов. Напишите сценарий в YAML, и готово. Направление толкать , а не тянуть . По умолчанию он подключается к целевым хостам с помощью SSH или WinRM в случае ящиков Windows. Если вы привыкли писать это install.shили install.ps1, вы почувствуете себя как дома, изменив это на install.yamlи получив все преимущества платформы автоматизации Ansible.

Ansible также можно использовать для подключения к различным API-интерфейсам для подготовки облачных серверов или для настройки кластеров Kubernetes. Таким образом, его можно использовать в качестве дополнительного инструмента или замены Terraform , и ничто не мешает вам создавать манифесты Kubernetes YAML, наполненные шаблонами Jinja2, и развертывать их с помощью Ansible , а не Helm .

Но поскольку ландшафт инструментов с открытым исходным кодом огромен, возникает вопрос: должны ли вы?

В чем он хорош?

Как было сказано ранее, начать работу с ним несложно. Распространяемый как единый пакет Python, Ansible поставляется со всем, кроме кухонной раковины .

До версии 2.10 , которая в настоящее время находится в разработке, это особенно верно, поскольку в ядре Ansible есть такие модули, как package и win_service , которые управляют обещанными ресурсами с их именами. Но есть и более специфические модули . Идите вперед и запускайте планы Terraform с помощью Ansible. Все это с помощью сингла pip install ansible. После выхода версии 2.10 пользовательский интерфейс может не сильно измениться, но в будущем модули будут жить вне ядра в коллекциях и ими можно будет управлять отдельно.

Ansible также широко используется для управления сетевым оборудованием. От маршрутизаторов до коммутаторов, безагентная архитектура делает Ansible хорошим выбором для автоматизации довольно утомительных задач по назначению VLAN в оборудовании Cisco или интерфейсах Juniper Junos. В этих случаях подключение к устройствам отличается от SSH по умолчанию. Благодаря архитектуре плагинов такие протоколы, как NETCONF, можно использовать для управления всеми вещами.

Написанный на Python, Ansible легко расширяется. Так что если в списке выше нет нужного вам модуля, вы можете написать какой-нибудь свой или расширить включенные фильтры Jinja2 с помощью плагина . Чаще всего достаточно готовых модулей и желаемое состояние системы достигается комбинацией задач.

Ansible также удобен для глаз. Задачи для запуска написаны на YAML, который де-факто становится языком конфигурации многих других современных инструментов. Он приносит с собой некоторые подводные камни, но в основном это список задач…

- hosts: localhost
# Use sudo to become root.
become: true
tasks:
- name: Install Apache
package:
name: apache2
state: present
- name: Start and enable Apache
service:
name: apache2
state: started
enabled: true

…легко понимается и не системным администратором.

С Ansible легко делать простые вещи, а более сложные задачи не слишком сложны, поскольку Ansible допускает циклы и другие конструкции , которые делают YAML шагом к реальному языку программирования, где возможно все. Синтаксис Ansible находится где-то между императивным и декларативным, в основном ближе к последнему по оси парадигм программирования. Вы сосредотачиваетесь на том, чего хотите, а не на том, как . Пуристы также определят императивные аспекты. Если ничего не помогает, добавьте немного кода Python в блок шаблонов Jinja2, чтобы выполнить даже самую сложную задачу.

Помимо написания плейбуков для выполнения задач, в Ansible есть концепция, называемая специальной командой , которую можно использовать для внесения изменений в работающие системы без написания какого-либо YAML. Например, чтобы перезапустить все экземпляры Apache на всех хостах в webserversгруппе. Это похоже на подключение по SSH ко всем хостам и запуск systemctl restart apache2. Это и синтаксис делают Ansible очень подходящим для ситуаций, когда оператор очень привык к управлению системами, но ему нужны руки робота, чтобы помочь с управлением парком.

Если вы стремитесь создать неизменяемую инфраструктуру, подобную той, которая обычно связана с запуском контейнеров, Ansible можно пометить вместе с Packer . При совместном использовании Ansible управляет состоянием развертываемых образов. Также доступен Ansible-ориентированный способ создания контейнеров, так как чистый синтаксис Dockerfile может начать вас раздражать в какой-то момент.

Кстати, короткий фрагмент выше полностью функционален! Вы можете поместить его в файл с именем playbook.ymlи запустить команду ansible-playbook -i localhost playbook.ymlпосле установки самого Ansible. Без каких-либо изменений он установит и запустит Apache в системе Linux на основе Debian. Просто для начала, не так ли?

Каковы недостатки?

Теперь вы могли бы вести со мной продолжительную дискуссию, и я мог бы убедить вас, что их нет. Но ради реализма… чтобы мои коллеги были счастливы , есть некоторые вещи, которые могут вас раздражать в Ansible.

У Jinja2 есть свои особенности, одна из которых — обработка всего как строки по умолчанию, так как по своей сути он предназначен для рендеринга текстовых файлов. Будьте готовы немного потанцевать с целыми числами. Некоторый прогресс был достигнут из темных дней, но вам все еще нужно включить его .

YAML. Что ж, YAML хорош и все такое, но обманчиво прост. На самом деле это довольно сложно , и вы можете, например, определить многострочную строку миллионом способов. Достаточно, чтобы гарантировать наличие специального веб-сайта: yaml-multiline.info . Логические значения также могут быть выражены разными способами, поэтому в некоторых местах вы можете увидеть yesвместо . trueОба варианта синтаксически правильны , но для ясности следует придерживаться одного из них. Просто помните, что Norway тоже ложнаNO , так как интерпретируется как логическое значение. Не забывайте также правильно делать отступ в каждой строке. Неправильный размер отступа в большинстве случаев приводит к ошибке или неправильному толкованию в остальных.

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

Ansible также не имеет состояния по своей конструкции, поэтому по сравнению с обработкой состояния Terraform ему необходимо идти и проверять каждый ресурс, каждый раз, когда он сталкивается с задачей, которую вы создали для управления состоянием указанного ресурса. Получить хорошую разницу изменений за один раз невозможно, например, в Terraform или Helm. В сочетании с линейной стратегией по умолчанию будьте готовы ждать, пока ваша 1000-я задача внесет свои изменения после того, как 999 впервые будут отмечены знаком ok. Есть несколько способов ограничить это время ожидания, но у Ansible нет способа узнать , что модификация есть только у последней задачи, а у остальных нет, пока она не дойдет до конца.

Также нет реальных зависимостей между ресурсами, как в Puppet и Terraform. В то время как вы можете получать выходные данные задач registerи использовать их в качестве входных данных в другом месте, а также можете notifyиспользовать другие ресурсы handlersво время изменений. Вы не можете получить график всех ресурсов в ваших книгах и ролях.

Ansible отлично работает, когда у вас есть ограниченное количество администраторов, выполняющих команды. Все они имеют контроль доступа на стороне «корневого доступа» спектра разрешений. У него нет механизма блокировки, если только вы его не создадите, поэтому ничто не мешает вам запускать конфликтующие изменения из нескольких мест одновременно. Контроль версий настоятельно рекомендуется с плейбуками, но из-за этого обработка ветвей может потребовать некоторой работы со стороны пользователя. Вы можете начать мечтать о сервере, как в Chef или Puppet, когда достигнете определенного уровня. Для контроля доступа, централизованного управления или при наличии пользователей с разной степенью разрешений.

Можно также сказать, что безагентная push-архитектура имеет свои ограничения, но давайте согласимся, что у другого направления тоже есть проблемы, и они подходят для разных типов вариантов использования. Среди всех плюсов и минусов возникает еще один вопрос: когда следует выбирать Ansible в качестве предпочтительного инструмента?

Когда я должен выбрать Ansible вместо альтернатив?

Ansible отлично справляется с управлением серверами и инфраструктурой Unix-y. Написание ролей и управление установкой, настройкой и запуском таких сервисов, как Apache, Elasticsearch или MariaDB. Он также имеет множество модулей, связанных с сетью, поэтому Ansible чувствует себя как дома в центре обработки данных. Места, где среда немного более статична по сравнению с эфемерной природой контейнеров.

Специальные команды и простой синтаксис делают его хорошим инструментом для операторов. Чтобы быстро начать работу, старые скрипты и штуковины можно преобразовать в YAML с меньшими усилиями, чем научиться писать Ruby для Chef, терраформировать все или перейти на новый способ работы с контейнерами и Kubernetes.

У Ansible нет ни пользовательского интерфейса, ни сервера, если не считать Ansible Tower от RedHat. Таким образом, он обслуживает пользователей, разбирающихся в командной строке, лучше, чем люди, привыкшие нажимать кнопки. Говоря о Tower, он позволяет визуализировать и централизовать использование Ansible. Он также предоставляет вам API и контроль доступа. Это также идет с ценником. В качестве альтернативы AWX — это исходная версия Tower с открытым исходным кодом.

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

При работе с общедоступными облаками, такими как AWS, Azure или GCP, консенсус, похоже, заключается в том, чтобы использовать Terraform для подготовки. Вполне возможно, из-за указанной выше причины обработки состояния. Но Terraform не преуспевает в управлении содержимым серверов, поэтому, возможно, продолжайте управлять конфигурацией с помощью Ansible. Однако это плохо работает с автоматическим масштабированием и другими действиями по оркестровке. Поэтому лучшим вариантом было бы создать изображения с помощью Ansible, а затем отправить их в облако с помощью Terraform. После этого выполните любое автомасштабирование и восстановление после сбоя с неизменяемыми образами. Что касается операций, Ansible будет удобен благодаря специальным командам и быстрому написанию плейбуков.

Облачные провайдеры также имеют свои собственные способы ведения дел. Я слышал хорошие отзывы о CDK от Amazon, но никогда им не пользовался. Поскольку это фактически код-код , а не вид-кода Ansible , он зависит от вашего опыта и личных предпочтений, а также от возможностей программного обеспечения. И даже с CDK вы получаете промежуточный декларативный CloudFormation . У Azure есть свой Resource Manager , а Google назвал их Deployment Manager . Но облачные технологии — это именно облачные технологии . При выборе инструментов я вижу большую ценность в том, чтобы придерживаться более широкого круга задач.

Например, в OpenStack я лично предпочел бы Ansible писать шаблоны Heat при предоставлении основных ресурсов. Инструмент более общий, и я думаю, что лучше быть экспертом Ansible, чем экспертом OpenStack Heat. Шаблоны Heat, как правило, со временем становятся все более запутанными и чрезмерно сложными. Но существуют некоторые ограничения на то, что поддерживают текущие модули OpenStack, поэтому необходимость управления новейшими компонентами OpenStack может ограничить ваш выбор инструментов. Однако после перехода к collections разработка модуля, похоже, набирает обороты. Говоря об OpenStack, OpenStack-Ansible — хороший проект для развертывания самого OpenStack.

Поддерживается управление серверами Windows, но модули Windows хранятся отдельно от вариантов Linux. Их также гораздо меньше по количеству. Переход с Ubuntu на RedHat менее болезненный и требует меньше изменений в YAML, чем переход с Ubuntu на Windows. Контроллер Ansible также должен быть основан на Unix, и, хотя теоретически возможно использовать для этого WSL, он не поддерживается и не рекомендуется для использования в производстве.

Но дело в том, что вы не ограничены только одним инструментом! Ansible отлично работает в сочетании с Terraform. Вы можете использовать его для создания некоторых кластеров Kubernetes локально или в облаке , а затем использовать Helm для управления самими развертываниями. Вы также можете более глубоко подключить Ansible к Kubernetes с помощью Operator SDK . Вы можете использовать его для создания образов контейнеров, а также образов виртуальных машин для достижения неизменности в производственных средах. И, помимо различных альтернатив, он действительно превосходен в управлении сетевым оборудованием, поэтому вы можете подключить его к NetBox .

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

Статья является переводом medium.com

17.12.2022 0 comment

Бизнес в итернете

Непрерывное развертывание инфраструктуры AWS без доверия стороннему CI

by moiseevrus 17.12.2022

written by moiseevrus

Я работал со многими клиентами, которые размещают свою производственную инфраструктуру на AWS, но их конвейеры CI размещаются у стороннего поставщика, такого как Travis, Wercker и CircleCI. Довольно легко понять, почему: сторонние ЭК очень просты в настройке и использовании! У них также есть неплохая документация, и они широко используются в проектах с открытым исходным кодом. CI обычно используется для запуска тестов, создания артефактов выпуска, а иногда даже для развертывания приложений.

Однако многие команды чувствуют себя неловко, когда дело доходит до использования CI для развертывания изменений инфраструктуры. Обычно это происходит не потому, что они не доверяют автоматизированному процессу, а потому, что они не хотят предоставлять широкий доступ к учетным записям AWS, которые обычно требуются при управлении инфраструктурой как кодом.

Однако я обнаружил, что автоматизация изменений инфраструктуры может быть полезной. Я думаю, что это значительно снижает когнитивную нагрузку, когда речь идет о синхронизации вашей инфраструктуры. Итак, есть ли способ, которым мы могли бы по-прежнему обеспечивать непрерывное развертывание для изменений инфраструктуры, не доверяя стороннему CI? В этой статье я представлю одно решение этой проблемы. В основном я работаю с AWS, поэтому я создал решение специально для него.

Ограничения

Мы хотим автоматизировать изменения инфраструктуры, но есть ограничения. Давайте разберем проблему.

Ограничение № 1. Мы не хотим предоставлять стороннему CI доступ к инфраструктуре AWS, который позволит ему нанести какой-либо ущерб, если доступ по какой-либо причине попадет в чужие руки. Например, если произойдет утечка учетных данных AWS, назначенных CI, злоумышленник, использующий эти учетные данные, не сможет удалить наши базы данных и запустить крипто-майнеры.

Ограничение № 2: мы хотим, чтобы изменения инфраструктуры запускались без участия человека. Как только изменение кода инфраструктуры будет зафиксировано в основной ветке в репозитории Git, оно в конечном итоге будет развернуто в рабочей среде при условии, что остальные этапы автоматизации перед его выполнением будут успешно выполнены.

Ограничение № 3. Мы хотим, чтобы изменения инфраструктуры инициировались после конвейера CI, подключенного к тому же репозиторию кода. Некоторые репозитории Git могут содержать как код приложения, так и код инфраструктуры. Например, репозиторий Git может содержать исходный код веб-приложения и код инфраструктуры для развертывания приложения и окружающих служб (например, корзины S3, экземпляры RDS). В этих случаях важно убедиться, что изменения инфраструктуры не выполняются, если тесты не пройдены в конвейере CI.

Ограничение № 4. Мы хотим, чтобы это решение работало с несколькими репозиториями Git. Как упоминалось в приведенном выше ограничении, у нас может быть код инфраструктуры, совмещенный с кодом приложения, а это означает, что нам необходимо поддерживать изменения инфраструктуры, поступающие из нескольких репозиториев.

Грубый архитектурный эскиз

Имея в виду эти ограничения, давайте представим, как примерно будет выглядеть архитектура.

Если мы хотим развернуть изменения инфраструктуры AWS, но в то же время сделать это безопасно, обычно рекомендуется запускать их в самом AWS. Таким образом, вам нужно доверять только AWS, а не дополнительным третьим сторонам. В конце концов, вы уже доверяете AWS свою инфраструктуру. Кроме того, если вы развертываете изменения из AWS, вы можете использовать роли IAM, которыми гораздо сложнее злоупотреблять, чем пользователями IAM .

Предполагая, что у нас есть этот волшебный деплойер, размещенный в AWS, нам нужен способ его запуска. Если мы запустим его напрямую от нашего поставщика Git (например, веб-перехватчики Github), мы не можем гарантировать, что он будет работать после завершения конвейера CI (ограничение № 3). По этой причине мы предоставим возможность запускать деплойер для репозитория по запросу из CI (ограничение № 2), но не более того. Разработчик по-прежнему будет нести ответственность за получение исходного кода и любых других деталей, связанных с запуском развертывания, вместо того, чтобы доверять CI передавать правильную информацию (ограничение № 1).

Нам также нужен регистр, чтобы содержать информацию о том, какие именно репозитории можно использовать с развертывателем. Когда развертыватель запускается, он проверяет данные репозитория из реестра. Таким образом, мы можем поддерживать несколько исходных репозиториев с одним и тем же деплойером (ограничение № 4), но также убедиться, что мы не запускаем код из произвольных источников. Мы также можем включить в реестр такую информацию, как данные аутентификации Git и команды развертывания.

Поиск решений

Давайте заглянем в нашу кучу LEGO, которая является каталогом продуктов AWS , и посмотрим, какие компоненты мы можем найти для решения нашей проблемы.

КодБилд

Что мы действительно хотим сделать, так это непрерывное развертывание на AWS, и AWS рекомендует использовать для этого CodePipeline и CodeBuild. Подводя итог, можно сказать, что CodePipeline — это решение для связывания различных шагов для формирования конвейера доставки вашего кода, а CodeBuild предназначен для работы в качестве шага в конвейере, который запускает произвольные команды, такие как тесты и упаковка программного обеспечения.

Поскольку все, что мы хотим сделать, это запустить один шаг, развернуть код инфраструктуры, CodeBuild должно быть достаточно для наших целей. CodeBuild может запускать контейнеры Docker, поэтому мы можем создать собственный образ Docker, включающий весь код и инструменты, необходимые для получения исходного репозитория и внесения изменений в инфраструктуру. Затем мы можем выполнить его независимо, используя вызов API StartBuild .

Проксирование вызовов CodeBuild

Итак, мы просто создадим проект CodeBuild и предоставим возможность вызывать API StartBuild из стороннего CI, верно? К сожалению, это раскрывает слишком многое. API StartBuild позволяет вам переопределить множество деталей, указанных в проекте CodeBuild, в том числе какие команды запускать. В случае утечки доступа к API злоумышленник, имеющий доступ, может выполнять произвольные команды в нашей инфраструктуре AWS.

Если бы только у нас был какой-то прокси для соединения и фильтрации вызовов от стороннего CI к CodeBuild.

Я сомневаюсь, что у AWS есть продукт, специально предназначенный для решения этой проблемы, но мы всегда можем положиться на Lambda — часть AWS LEGO 2×4 — чтобы склеить эти части вместе. Мы можем создать тему SNS, где CI может отправить сообщение, чтобы инициировать развертывание в AWS. Затем тема SNS запускает функцию Lambda, которая запускает задание CodeBuild. Мы также можем использовать функцию Lambda для проверки репозитория и запускать задание CodeBuild только в том случае, если репозиторий находится в белом списке.

параметры ССМ

Нам по-прежнему нужно место для хранения сведений о том, какие репозитории можно использовать с развертывателем. Я обнаружил, что параметры SSM являются полезным решением для записи произвольных пар ключ-значение небольшого объема. Он также поддерживает IAM для управления доступом и KMS для шифрования значений, поэтому мы можем ограничить, кто может изменять список репозиториев, внесенных в белый список для развертывателя, и безопасно хранить учетные данные Git.

Диаграмма архитектуры

Теперь, когда мы заполнили недостающие части, вот как выглядит наша архитектура.

Покажи мне код!

Это не было бы большой демонстрацией, если бы я просто показал вам кучу архитектурных диаграмм. Давайте посмотрим на некоторые примеры кода.

У меня есть полный пример, размещенный в репозитории GitHub: I Wanna Own My Pipeline in AWS . Я создал его с помощью AWS CDK с TypeScript в качестве языка программирования, но здесь подойдет практически любой инструмент «инфраструктура как код» с поддержкой AWS.

Информация о проекте в параметрах SSM

Во-первых, давайте посмотрим, как мы храним информацию о проекте в параметрах SSM.

Я решил разместить всю информацию о проекте по одному корневому пути ( /iwomp-in-aws), при этом каждый проект имеет один параметр, содержащий все необходимые сведения в формате JSON. JSON включает следующие ключи:

gitUrl: URL-адрес репозитория Git, из которого нужно извлечь код.
authToken: Токен для аутентификации на основе токенов. (по желанию)
basicUsername: Имя пользователя для базовой аутентификации. (по желанию)
basicPassword: Пароль для базовой аутентификации. (по желанию)
deployDir: Каталог, в котором находится весь код инфраструктуры. По умолчанию: корневой каталог Git. (по желанию)
command: команда для развертывания изменений инфраструктуры. Обратите внимание, что одна и та же команда выполняется всегда для каждого запуска, поэтому, если вам нужно выполнить какую-либо фильтрацию веток Git, это необходимо учитывать в сценарии.

Например, /iwomp-in-aws/demoможет содержать следующий документ JSON:

{ 
"gitUrl": "https://github.com/jkpl/cdk-demo ", 
"command": "./deploy.sh" 
}

Проект использует «demo» в качестве идентификатора проекта, код извлекается из репозитория cdk-demo, и ./deploy.shкоманда выполняется каждый раз, когда запускается деплойер.

Информация о проекте может управляться вручную или автоматически. Любой способ работает лучше всего для вас. Репозиторий Git содержит пример того, как управлять проектами с помощью CDK .

Проект CodeBuild

Поскольку мы собираемся запускать собственный контейнер Docker в CodeBuild, мы сначала настроим репозиторий ECR для размещения образов Docker . Я расскажу о содержимом образа Docker в следующем разделе.

import * as ecr from '@aws-cdk/aws-ecr';
const containerImageRepo = new ecr.Repository(this, 'repo', {
repositoryName: 'iwomp-in-aws',
});

Теперь мы можем создать проект CodeBuild для нашего деплойнера . Мы настроим его на чтение образа Docker из репозитория ECR выше и запустим команду развертывания iwomp-in-aws, доступную в образе. Я дополнительно установлю CONFIGPATHпеременную среды, которая сообщает контейнеру, где мы можем найти всю информацию о проекте в параметрах SSM.

import * as codebuild from '@aws-cdk/aws-codebuild';
const configPath = iwompProps.configPath || 'iwomp-in-aws';
const worker = new codebuild.Project(this, 'worker', {
buildSpec: codebuild.BuildSpec.fromObject({
version: '0.2',
phases: {
build: {
commands: ['iwomp-in-aws'],
},
},
}),
description: 'iwomp-in-aws worker',
environment: {
buildImage: codebuild.LinuxBuildImage.fromEcrRepository(containerImageRepo),
computeType: codebuild.ComputeType.SMALL,
environmentVariables: {
'CONFIGPATH': {value: configPath},
}
},
});

Нам потребуется предоставить IAM-разрешения проекту CodeBuild, чтобы он работал. CDK автоматически создаст роль IAM для проекта CodeBuild, которому мы можем предоставить разрешение. Во- первых, нам нужно предоставить ему доступ для чтения параметров SSM .

import * as iam from '@aws-cdk/aws-iam';
const configPath = iwompProps.configPath || 'iwomp-in-aws';
const configPathArn = this.formatArn({
service: 'ssm',
resource: `parameter/${configPath}/*`
});
worker.addToRolePolicy(new iam.PolicyStatement({
effect: iam.Effect.ALLOW,
resources: [configPathArn],
actions: ['ssm:GetParameter'],
}));

Мы также хотим предоставить доступ к управлению другими сервисами AWS, которыми мы хотим управлять автоматически. В репозитории Git есть один пример того, как это сделать .

Инструмент развертывания

Проекту CodeBuild требуется специальный инструмент для клонирования исходного репозитория Git и выполнения команды развертывания в соответствии с информацией, хранящейся в параметрах SSM. Это iwomp-in-awsкоманда, упомянутая в последнем разделе.

Я решил закодировать инструмент, используя Go в качестве языка программирования, потому что я знаком с ним, и поскольку он создает статические двоичные файлы, я могу просто вставить любой образ Docker.

Параметры запуска инструмента считываются из переменных среды с помощью envconfig . Эти параметры предоставляются при запуске задания CodeBuild.

package mainimport (
	"fmt"
	"log"
	"github.com/kelseyhightower/envconfig"
)type appConfig struct {
	ConfigPath  string `default:"iwomp-in-aws"`
	ProjectName string `required:"true"`
	GitBranch   string `required:"true"`
}

func (c *appConfig) projectPath() string {
	return fmt.Sprintf("/%s/%s", c.ConfigPath, c.ProjectName)
}

func (c *appConfig) load() error {
	return envconfig.Process("", c)
}func main() {
	if err := mainWithErr(); err != nil {
		log.Fatalf("iwomp-in-aws: %s", err)
	}
}

func mainWithErr() error {
	// Load app config
	var appConf appConfig
	if err := appConf.load(); err != nil {
		return err
	}
	// continued in the next code block ...
}

Вот для чего нужны конфигурации:

ConfigPath: базовый путь для параметров SSM.
ProjectName: Имя проекта для развертывания. Имя должно совпадать с идентификатором проекта в параметрах SSM. Например, если установлено значение demo и ConfigPathиспользуется значение по умолчанию, сведения о проекте извлекаются из параметра SSM /iwomp-in-aws/demo.
GitBranch: имя ветки Git для клонирования проекта.

Далее мы загрузим конфигурацию проекта из параметров SSM.

import (
	"encoding/json"
	"github.com/aws/aws-sdk-go/aws"
	"github.com/aws/aws-sdk-go/aws/session"
	"github.com/aws/aws-sdk-go/service/ssm"
)type projectConfig struct {
	GitURL        string `json:"gitUrl"`
	AuthToken     string `json:"authToken"`
	BasicUsername string `json:"basicUsername"`
	BasicPassword string `json:"basicPassword"`
	DeployDir     string `json:"deployDir"`
	Command       string `json:"command"`
}func (c *projectConfig) load(ac *appConfig, sess *session.Session) error {
	ssmSVC := ssm.New(sess)

	projectPath := ac.projectPath()
	projectOut, err := ssmSVC.GetParameter(&ssm.GetParameterInput{
		Name:           aws.String(projectPath),
		WithDecryption: aws.Bool(true),
	})
	if err != nil {
		return fmt.Errorf("failed to fetch from SSM path %s: %s", projectPath, err)
	}
	if err := c.loadFromParameter(projectOut.Parameter); err != nil {
		return fmt.Errorf("failed to load from SSM path %s: %s", projectPath, err)
	}

	// Fill in the gaps
	if c.DeployDir == "" {
		c.DeployDir = "."
	}

	// Validate
	if c.GitURL == "" {
		return fmt.Errorf("no Git URL specified for project %s", ac.ProjectName)
	}
	if c.Command == "" {
		return fmt.Errorf("no command specified for project %s", ac.ProjectName)
	}

	return nil
}

func (c *projectConfig) loadFromParameter(parameter *ssm.Parameter) error {
	return json.Unmarshal([]byte(*parameter.Value), c)
}func mainWithErr() error {
	// continued from the previous code block ...

	// Start AWS session
	sess, err := session.NewSession(&aws.Config{})
	if err != nil {
		return err
	}

	// Load config for the project
	var projectConf projectConfig
	if err := projectConf.load(&appConf, sess); err != nil {
		return err
	}

	// continued in the next code block ...
}

Конфигурация проекта включает в себя все параметры, перечисленные в разделе «Информация о проекте в параметрах SSM». Как упоминалось ранее, мы загрузим один параметр SSM и проанализируем его содержимое как JSON. Некоторые параметры имеют разумные значения по умолчанию, поэтому мы просто восполним пробелы, если они есть. Мы также проверим, что по крайней мере URL-адрес Git и команда развертывания были указаны, и быстро завершится сбой, если они не указаны.

Получив всю информацию о проекте, мы можем продолжить и клонировать репозиторий Git, используя эту удобную библиотеку Go .

import (
	git "github.com/go-git/go-git/v5"
	gitPlumbing "github.com/go-git/go-git/v5/plumbing"
	gitTransport "github.com/go-git/go-git/v5/plumbing/transport"
	gitHTTP "github.com/go-git/go-git/v5/plumbing/transport/http"
)func (c *projectConfig) gitAuth() gitTransport.AuthMethod {
	if c.AuthToken != "" {
		return &gitHTTP.TokenAuth{
			Token: c.AuthToken,
		}
	}
	if c.BasicPassword != "" {
		return &gitHTTP.BasicAuth{
			Username: c.BasicUsername,
			Password: c.BasicPassword,
		}
	}

	return nil
}func cloneRepository(appConf *appConfig, projectConf *projectConfig) error {
	log.Printf("cloning repo %s branch %s", projectConf.GitURL, appConf.GitBranch)

	_, err := git.PlainClone(".", false, &git.CloneOptions{
		URL:           projectConf.GitURL,
		Auth:          projectConf.gitAuth(),
		ReferenceName: gitPlumbing.NewBranchReferenceName(appConf.GitBranch),
		SingleBranch:  true,
		Progress:      os.Stdout,
		Depth:         1,
	})
	return err
}func mainWithErr() error {
	// continued from the previous code block ...	// Clone repo for the project based on app config
	if err := cloneRepository(&appConf, &projectConf); err != nil {
		return err
	}

	// continued in the next code block ...
}

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

Наконец, мы можем выполнить команду развертывания, указанную для проекта.

import (
	"os"
	"os/exec"
)func (c *projectConfig) run(appConf *appConfig) error {
	cmd := exec.Command(c.Command, appConf.GitBranch)
	cmd.Dir = c.DeployDir
	cmd.Stdout = os.Stdout
	cmd.Stderr = os.Stderr
	return cmd.Run()
}func mainWithErr() error {
	// continued from the previous code block ...

	// Run the project command
	return projectConf.run(&appConf)
}

Вы можете найти полный исходный код этого инструмента в репозитории Git .

Развертывание Docker-образа

Нам нужен образ Docker для обработки процесса развертывания. Он должен включать следующее:

Инструмент развертывания из предыдущего раздела.
Фоновые зависимости, необходимые для выполнения фактического развертывания. Например, CDK, Terraform, Pulumi или любой другой инструмент, который вы хотите использовать для управления инфраструктурой AWS.

Начнем с создания инструмента развертывания на этапе сборки в Docker:

FROM golang:1.14 as builder

WORKDIR /project

# Download dependencies
COPY go.mod go.sum ./
RUN go mod download

# Build the app
COPY main.go ./
RUN CGO_ENABLED=0 go build -o iwomp-in-aws

Создав инструмент, мы можем подготовить образ Docker для нашего проекта CodeBuild.

FROM node:14-slim

# Install system packages
RUN apt-get update && \
    apt-get install -y ca-certificates && \
    rm -rf /var/lib/apt/lists/*

# Install CDK
RUN npm install -g aws-cdk

# Non-root user
RUN groupadd -g 10101 cdk && \
    useradd -m -d /project -g cdk -u 10101 cdk
USER cdk:cdk
WORKDIR /project

# Runner script
COPY --from=builder /project/iwomp-in-aws /usr/bin/iwomp-in-aws
ENTRYPOINT [ "iwomp-in-aws" ]

Последнее, что нам осталось сделать, — это создать образ Docker и отправить его в репозиторий ECR , который мы создали ранее.

Лямбда-функция

Далее давайте посмотрим на функцию Lambda, которая используется для запуска развертывателя.

Мы создадим обработчик JavaScript для приема событий SNS. Во-первых, мы проверим входящее событие, чтобы оно содержало достаточно информации. Он должен содержать идентификатор проекта и ветку Git, содержащую код инфраструктуры.

exports.handler = async function(event) {
    if (!event.Records[0]) {
        throw new Error('No SNS event found');
    }
    const message = parseMessage(event.Records[0].Sns.Message);
    // continued in the next code block ...
}function parseMessage(message) {
    const json = JSON.parse(message);
    if (!json.project) {
        throw new Error('No project name provided');
    }
    if (!json.branch) {
        throw new Error('No branch provided');
    }
    return json;
}

Далее мы проверим наличие проекта в белом списке, проверив, что он записан в параметрах SSM. Базовый путь для параметров SSM предоставляется через CONFIGPATHпеременную среды.

const aws = require('aws-sdk');
const ssm = new aws.SSM();exports.handler = async function(event) {
    // continued from the previous code block ...
    try {
        await validateProject(message.project);
    } catch (e) {
        throw new Error(`Invalid project ${message.project}: ${e.message}`);
    }
    // continued in the next code block ...
};async function validateProject(project) {
    const ssmPath = `/${process.env.CONFIGPATH}/${project}`
    const params = {
        Name: ssmPath,
        WithDecryption: true
    };
    const parameter = await ssm.getParameter(params).promise();
    const json = JSON.parse(parameter.Parameter.Value);
    if (!json.gitUrl) {
        throw new Error('No Git URL set');
    }
}

Наконец, мы запустим задание CodeBuild, используя сведения о событии. Lambda прочитает имя задания CodeBuild из WORKER_PROJECT_NAME переменной среды. Мы передадим в задание имя проекта и ветку Git в качестве переменных среды. Инструмент, который мы создали с помощью Go, будет читать их с помощью envconfig, как показано ранее.

const codebuild = new aws.CodeBuild();exports.handler = async function(event) {
    // continued from the previous code block ...
    await launchWorkerJob(message);
    return 'ok';
};async function launchWorkerJob(message) {
    console.log(`Triggering job for project ${message.project} on branch ${message.branch}`);
    const params = {
        projectName: process.env.WORKER_PROJECT_NAME,
        environmentVariablesOverride: [
            {
                name: 'PROJECTNAME',
                value: message.project,
            },
            {
                name: 'GITBRANCH',
                value: message.branch,
            },
        ],
    };
    const data = await codebuild.startBuild(params).promise();
    console.log(`Job started: ${data.build.id}`);
    return data;
}

Развертывание лямбда-функции

Мы можем использовать CDK для развертывания функции Lambda . Код загружается из каталога с таким именем lambda, расположенного в том же репозитории. Здесь мы передадим путь конфигурации и имя проекта CodeBuild в лямбда-код в качестве переменных среды.

import * as lambda from '@aws-cdk/aws-lambda';
const launcher = new lambda.Function(this, 'launcher', {
runtime: lambda.Runtime.NODEJS_12_X,
handler: 'index.handler',
code: lambda.Code.fromAsset(path.join(__dirname, '..', 'lambda')),
description: "iwomp-in-aws launcher",
environment: {
'CONFIGPATH': configPath,
'WORKER_PROJECT_NAME': worker.projectName,
},
});

Lambda также нуждается в доступе для запуска заданий CodeBuild и чтения параметров SSM .

const configPathArn = this.formatArn({
service: 'ssm',
resource: `parameter/${configPath}/*`
});
launcher.addToRolePolicy(new iam.PolicyStatement({
effect: iam.Effect.ALLOW,
resources: [worker.projectArn],
actions: ['codebuild:StartBuild']
}))
launcher.addToRolePolicy(new iam.PolicyStatement({
effect: iam.Effect.ALLOW,
resources: [configPathArn],
actions: ['ssm:GetParameter'],
}));

Нам также понадобится тема SNS для входящих событий , и она должна быть подключена к Lambda , которую мы создали ранее.

import * as sns from '@aws-cdk/aws-sns';
import * as lambdaES from '@aws-cdk/aws-lambda-event-sources';
const jobTopic = new sns.Topic(this, 'topic', {});
launcher.addEventSource(new lambdaES.SnsEventSource(jobTopic));

Запуск развертывания из стороннего CI

Теперь у нас должен быть настроен конвейер развертывания в AWS. Теперь нам просто нужно запустить его из стороннего CI. Мы можем сделать это с помощью команды публикации SNS в интерфейсе командной строки AWS.

aws sns publish \ 
  --topic-arn "$TOPIC_ARN" \ 
  --message "{\"project\": \"$PROJECT\", \"branch\": \"$BRANCH\"}"

Это опубликует событие SNS в формате JSON, содержащее два поля projectи branch. Нам нужно указать три параметра:

TOPIC_ARN: ARN для темы SNS, которую мы создали ранее.
PROJECT: идентификатор проекта. Напримерdemo
BRANCH: ветка Git, из которой запускается этот конвейер.

В качестве альтернативы мы можем использовать скрипт, который самостоятельно определяет тему ARN и ветку .

Выводы

В этой статье я рассмотрел решение для автоматического запуска изменений кода инфраструктуры AWS, не доверяя сторонним поставщикам CI. Я разбил проблему на четыре ограничения и разработал решение, исходя из них. Наконец, я рассмотрел код, используемый для управления решением.

Этот пост оказался немного длиннее, чем я изначально ожидал. Однако пусть это не обескураживает вас! Там довольно много кода, чтобы настроить все это, но на самом деле нет никаких компонентов, которые работают непрерывно. Вместо этого все компоненты основаны на сервисах AWS, счета за которые выставляются в зависимости от использования, что должно снизить затраты, когда конвейер не используется активно. Именно так, как мне нравится.

Конечно, в представленном мной решении есть много возможностей для расширений. Я не рассказывал о каких-либо механизмах публикации отзывов от развертывателя. Например, средство развертывания может быть расширено для отправки результатов развертывания обратно в сторонний CI, запросы на вытягивание GitHub или в Slack. Я также опустил некоторые детали, такие как аутентификация SSH для Git.

Статья является переводом medium.com

17.12.2022 0 comment

Newer Posts

Older Posts