фото Роберт Бейкер на Неспособный
- Обозначение автоматизации
- Определение того, что такое трубопровод
- Определение плана игры для автоматического отправки заявки в хранилище контейнера
- Настройка платформы непрерывной интеграции
- Разрушение реализации
Создание компилятора — нелегкая задача. Он включает в себя разработку многих модулей, таких как лексер, анализатор и виртуальная машина. Он также включает в себя обработку объявлений переменных (например, Int) и оценку простых арифметических выражений (например, * 10 + 2) вплоть до вызова возвращающихся функций с такими параметрами, как факториальная рекурсивная функция:
В соответствии с процессом мы обнаружили много вещей на этапе разработки, которые не рассматривались на этапе проектирования (клянусь, я никогда раньше не слышал об этой проблеме). В результате мы постоянно перемещали грамматику, чтобы убедиться, что кромки работали. Вот почему мы решили сделать шаг назад и воспользоваться преимуществами Unittest модуль, который предоставляет Python3. Для каждого .tl Файл, наше расширение файла языка программирования, мы создали тест. Это позволило нам вносить изменения быстрее, устраняя страх нарушения предыдущего рабочего кода.
Тесты были сосредоточены на трех разных категориях:
- Правильность промежуточной генерации кода (четырехлетные четырех человек)
- Ожидаемые сбои файлов .tl с ожидаемым количеством ошибок
- Правильность в ожидаемом выполненном выходе
В результате, делая сделать тест (Viva la Makefile) проходит 50+ тестов. Но что произойдет, если разработчик забудет запустить тесты, прежде чем выполнять запрос на тягу или слияние, чтобы освоить? К счастью, мы используем GitHub, так что возвращение к конкретному коммиту возможно, но практично ли это? Мы действительно хотим пройти этот болезненный путь?
Кроме того, трендлит Наш компилятор должен быть облачным. Так что это означает, что нам также нужен простой способ его развертывания. Вдобавок ко всему, так как Trendlit Запускается внутри контейнера Docker, нам также нужен способ построить изображение Docker, проверить, существует ли текущая версия в репозитории контейнера (например, Hub Docker) и в конечном итоге выдвините это изображение в реестр. Поэтому мы решили сделать это DevOps.
фото Тянь Куан на Неспособный
Трубопровод — это набор автоматизированных процессов, которые позволяют разработчикам и профессионалам DevOps надежно и эффективно компилировать, создавать и развернуть свой код на своих производственных вычислительных платформах. Не существует жесткого и быстрого правила, в котором говорится, что должен нравится трубопровод, и инструменты, которые он должен использовать, однако наиболее распространенными компонентами трубопровода являются; Автоматизация построения/непрерывная интеграция, автоматизация тестирования и автоматизация развертывания.
Как мы упоминали ранее, мы хотим управлять Trendlit DevOps Way. Для этого мы будем реализовать шаги непрерывной интеграции (CI), непрерывной доставки (CD) и инфраструктуры в качестве услуги (IAAS). Для этого поста мы собираемся сосредоточиться на непрерывной интеграционной части.
Зачем нам вообще хоть КИ?
Непрерывная интеграция — это практика разработки, которая требует, чтобы разработчики интегрировали код в общий репозиторий несколько раз в день. Затем каждая регистрация проверяется автоматической сборкой, позволяя командам рано обнаруживать проблемы. [5]
В результате ошибки могут быть обнаружены быстрее и могут быть обнаружены легче. Это позволяет организации доставлять программное обеспечение быстрее, снижая при этом риск для каждого выпуска.
В этом примере идея заключается в том, что разработчик, добавляя или исправляя функцию, может перейти от Localhost к приложению, которое подталкивается в реестр в течение нескольких минут, при этом полагаясь на автоматический процесс. Как мы собираемся достичь этого? Ну, как вы уже догадались: мы собираемся использовать трубопровод. Итак, рабочий процесс будет выглядеть примерно так:
Диаграмма, созданная Plantuml: https://bit.ly/2W1D6OR
- Разработчик добавляет новую функцию в приложение.
- Приложение проходит процесс автоматического тестирования.
- Когда разработчик делает запрос на вытяжение, приложение проходит под принципом Four-Eyes [4], и, если оно одобрено другим узлом и автоматическими тестами, новая функция объединяется с главной ветвью хранилища кода.
- Новая версия приложения автоматически создана и упакована в контейнер.
- Контейнер выдвигается в хранилище контейнера.
Чтобы запустить дорожную карту реализации, описанную выше, мы решили использовать следующий технический стек:
Код репозиторий
Мы будем использовать GitHub для размещения исходного кода приложения.
CI Платформа
Когда дело доходит до трубопроводов, мы можем найти их во всех цветах и вкусах. Для этого проекта мы решили пойти с Circleci, потому что он легко интегрируется с GitHub и позволяет SSH доступ к экземплярам сборки, что удобно для отладки шагов сборки. Стоит отметить, что мы могли бы заменить CiCleCi другим сервером автоматизации, таким как Дженкинс, но для настройки требуется больше времени, потому что он самостоятельно.
Контейнер репозиторий
Мы будем использовать хранилище, которое предоставляется Docker Hub Анкет
Это хранилище кода приложения: https://github.com/shekodn/trendlit-tutorial-1
Здесь вы также можете найти все сценарии, которые будет работать трубопровод, чтобы проверить, строить, проверить и подтолкнуть приложение в Docker Hub.
Шаги
- Вилка Проект , чтобы вы можете создать свой собственный трубопровод.
- Перейти к hub.docker.com и создать учетную запись и репозиторий с Trendlit-tutorial-1 как пространство имен.
- Зарегистрируйтесь в Circleci и связать свою учетную запись GitHub.
- Выберите разветвленную версию Trendlit-tutorial-1 и построить проект. Сборка потерпит неудачу, потому что вам нужно поместить учетные данные вашего Docker Hub. Также вам нужно изменить Репозиторий переменная в каждом сценарии BASH (или, по крайней мере, в docker_build.sh , docker_check.sh и docker_push.sh ) внутри сценарии Справочник по имени репозитория вашего Docker Hub.
- Не забудьте протолкнуть изменения в Мастер ветка.
- В приборной панели вашего Circleci в списке проектов перейдите к Trendlit-tutorial-1 Настройки, расположенные в https://circleci.com/gh/yourusername/trendlit-tutorial-1/edit
- Под Настройки сборки Вы увидите Переменные среды. Нажмите там и добавьте Docker_user и Docker_pass (a.k.a. Условные данные вашего Docker Hub) как переменные с их соответствующими значениями. Эти переменные позволят Circleci загружать контейнер приложения в хранилище вашего Docker Hub.
- Повторно запустите рабочий процесс, и на этот раз он должен преуспеть.
Это желаемый рабочий процесс после того, как запрос на притяжение объединяется с мастер ветка.
- После этого перейдите в свой концентратор Docker, и вы увидите три новых тега. Один с Trendlit’s Выпуск (a.k.a версия), который был указан в верхней части Makefile, Другой с сокращенной версией хэша коммита, а другой по имени самый последний. Если вы хотите узнать больше о помечении изображений Docker, вы можете посмотреть Здесь Анкет
Теги автоматически генерировались трубопроводом
Webhooks
Трубопровод способен Слушай Каждый раз, когда в репозитории происходит изменение благодаря Webhook. По словам GitHub, Webhooks Позвольте уведомлять внешние службы, когда произойдут определенные события. Когда возникают указанные события, GitHub отправляет запрос POST каждому из предоставленных URL -адресов [3].
Другими словами, когда вы связываете свою учетную запись GitHub с Circleci, вы позволяете последним выполнять некоторые действия в своих репозиториях. Один из них автоматически настраивает Webhook. Вы помните, когда мы впервые построили приложение? Ну, это было создано тогда. Поэтому каждый раз, когда есть событие, такое как толчок Компет или запрос на вытягивание, это Webhook Отправляет уведомление Circleci, чтобы вызвать сборку.
Если вы хотите увидеть, как Webhook Похоже, перейдите к настройкам проекта на GitHub и посмотрите. Там вы сможете увидеть, какие события запускают Webhook.
Репозиторий/настройки/веб -крючки
Разложение файла конфигурации
Как только сборка запускается Webhook , Circleci идет в config.yml Файл, расположенный внутри .circleci каталог.
1. Рабочие места
Трубопровод состоит из 2 основных рабочих мест: Тест и Развертывать.
2. Тесты
Здесь мы выбираем Docker в качестве типа исполнителя. Затем мы используем Python: 3.7-Alpine изображение, чтобы запустить некоторые тесты.
3. Развертывать
Здесь мы используем официальное изображение Docker под названием Docker: стабильный GIT , потому что нам нужно изображение Docker, которое устанавливает Docker и имеет git [1].
Тогда мы используем setup_remote_docker, Потому что в соответствии с Jpetazzo , мы должны дважды подумать, прежде чем использовать Docker внутри Docker [2]. В результате все команды Docker, такие как Docker Build и Docker push будет безопасно выполнено в этой новой среде.
Как вы могли заметить, Развернуть имеет несколько запустить Шаги:
- Мы бегаем APK добавить Make Чтобы получить версию выпуска Trendlit. Вы можете получить его в своем терминале, запустив сделать версию. Последний печатает Выпуск Переменная, расположенная в верхней части макияжа проекта.
- Помните, когда мы устанавливаем некоторые переменные окружающей среды? Что ж, вот и ты: мы бегаем Docker Login Таким образом, трубопровод имеет разрешение на то, чтобы вытащить контейнер Docker к соответствующему хранилищу контейнера.
- Мы используем docker_build.sh Чтобы построить контейнер Docker со следующим форматом: Репозиторий/изображение: тег Анкет
- После этого мы используем скрипт docker_check, чтобы проверить, существует ли текущий релиз в соответствующем репозитории контейнера. Вы помните Выпуск переменная, расположенная в верхней части Makefile ? Что ж, если версия уже существует, она сломает трубопровод, потому что вы не хотите перезаписать существующую версию, верно? Вы можете вручную исправить это, редактируя Makefile и назначить другую версию или вы можете запустить сделать удар Чтобы увеличить версию более плавным образом;)
- И последнее, но не менее важное: мы нажимаем изображение, которое docker_build.sh Ранее построен в Docker Hub.
4. Рабочие процессы
Здесь мы определили рабочий процесс с 2 заданиями: Тест и Развернуть Анкет Тест будет происходить каждый раз, когда изменение вносится в приложение в любом данном филиале, в то время как Развернуть всегда будет ждать Тест работа, чтобы закончить и будет работать только в Мастер ветка. Это потому, что мы не хотим строить и отправлять контейнер в реестр каждый раз, когда мы вносим изменение в филиале.
Хотя мы закончили Дорожная карта реализации Реализация в целом далеко не сделана. Легко взглянуть на все пропавшие вещи и соображения, но помните, с чего мы начали. Теперь у нас есть полностью автоматизированный процесс, который проверяет наше приложение и подталкивает его к хранилищу контейнера без какого -либо взаимодействия человека. Стоит отметить, что некоторые важные аспекты, такие как безопасность, пренебрегали, но это только одна часть MVP реализации (скоро непрерывная доставка).
Если у вас есть какие -либо предложения, я хотел бы услышать их. Я уверен, что мы можем включить их в будущие дорожные карты. Кстати, Получить запросы открыты;) Поэтому я хотел бы сотрудничать с вами, если вы думаете, что мы сможем улучшить процесс. А пока я буду работать над частью 2.
[0] https://www.bmc.com/blogs/deployment-pipeline/
[1] https://circleci.com/docs/2.0/executor-types/
[2] https://jpetazzo.github.io/2015/09/03/do-not-use-docker-in-docker-for-ci/
[3] https://developer.github.com/webhooks/
[4] https://whatis.techtarget.com/definition/four-eyes-principle
[5] https://www.thoughtworks.com/continuous-integration
Также опубликовано на Середина .
Оригинал: «https://dev.to/sergiodn/how-i-went-from-localhost-to-production-using-the-devops-way-part-1-of-n-4494»