Внедряването на CI/CD Pipeline или непрекъсната интеграция/непрекъснато внедряване е гръбнакът на съвременната DevOps среда. Той преодолява празнината между развойните и оперативните екипи чрез автоматизиране на изграждането, тестването и внедряването на приложения. В този блог ще научим какво е CI/CD тръбопровод и как работи с помощта на практически пример.

CI означава непрекъсната интеграция, а CD означава непрекъсната доставка/непрекъснато внедряване. Можете да мислите за това като за процес, подобен на жизнения цикъл на разработка на софтуер.

Нашата задача е да автоматизираме целия процес, от момента, в който екипът за разработка ни даде кода и го ангажира до момента, в който го пуснем в производство. Ние ще автоматизираме тръбопровода, за да направим целия жизнен цикъл на разработка на софтуер в DevOps/автоматичен режим. За целта ще ни трябват инструменти за автоматизация като Jenkins, Git/Github и Docker.

Jenkins ни предоставя различни интерфейси и инструменти, за да автоматизираме целия процес. Имаме Git хранилище, където екипът за разработка ще ангажира кода. След това Дженкинс поема оттам, инструмент отпред, където можете да дефинирате цялата си работа или задача. След това преминава към етапния сървър, за да го внедри с помощта на Docker. Това е точно като виртуална среда, в която можем да създадем сървър. Отнема няколко секунди, за да създадем цял сървър и да внедрим това, което искаме да тестваме.

Практическа автоматизация:

Разработчиците обикновено ангажират своя код към главния клон, който участва в производството. Преди да го изпратят към главния клон, те тестват своя код на друг клон (dev), за да се уверят, че няма грешка в кода. Екипът за въпроси и отговори ще провери кода и след това ще го обедини с главния клон. Така че ще създадем 3 задачи на Дженкинс за този процес.

РАБОТА 1: Ако Разработчикът натисне към разклонение за разработчици, тогава Дженкинс ще извлече от разработчиците и ще разположи в средата на разработчици.

РАБОТА 2: Ако Разработчикът натисне към главния клон, тогава Дженкинс ще извлече от главния и ще разположи в средата на главния докер. (Забележка: и средата на разработчиците, и средата на главния докер са в различни контейнери на докерите.)

РАБОТА 3: Ръчно QA екипът ще провери (тества) за уебсайта, работещ в средата за разработчици. Ако работи добре, тогава Дженкинс ще обедини клона dev към master клона и ще задейства JOB 2.

И така, започваме....

Забележка: - Ще изпълня всички стъпки на RHEL8.

Стъпка 1: Създайте локално git хранилище.

Команди:

  • mkdir име_на_директория
  • cd име_на_директория
  • git init
  • git дистанционно добавяне на произход github_url

Сега нашето git хранилище е създадено. Качете кода, който ви е необходим. Добавям HTML файл.

  • git добави начална страница.html
  • git commit homepage.html -m “коментари”
  • git push -u начален източник

Сега създайте клон за разработчици в същото репо:

  • git клон dev
  • git checkout dev //(за да влезете в клона на dev)
  • git push origin -all

Така че приключихме със създаването на репо.

Стъпка 2: Създайте уеб кукичка в git за автоматизация.

Настройте последващ ангажимент, който автоматично ще насочи кода към съответния клон и автоматично ще стартира заданието на Jenkins.

Команди:

  • cd .git/куки/
  • gedit след ангажиране

Код:

Използвайте свой собствен Jenkins URL, auth_token, потребителско име и парола.

#!/bin/bash
BRANCH=$(git rev-parse --abbrev-ref HEAD)
if [ "$BRANCH" ==  "master" ]
then
 git push origin master
 curl --user "user_name:password"
Jenkins_URL/job/Job1_master/build?token=auth_token
elif [ "$BRANCH" == "dev" ]
then
 git push origin dev
 curl --user "user_name:password" Jenkins_URL/job/Job2_dev/build?token=auth_token
fi

Стъпка 3: Стартирайте услугата Jenkins и докер

  • systemctl стартира Jenkins
  • systemctl стартиране на докер

Стъпка 4:Създайте отделна директория за управление на изтеглените кодове.

  • производство на mkdir
  • mkdir тестване

Стъпка 5: Създайте и конфигурирайте Jenkins job1.

Стъпка 6: Създайте и конфигурирайте Jenkins job2.

Стъпка 7: Създайте и конфигурирайте Jenkins job3.

Стъпка 8: Сега добавете нов файл към клона на разработчиците и ангажирайте промените. Той автоматично ще стартира задача 2 на Дженкинс и ще стартира контейнер в докер.

Сега екипът за въпроси и отговори ще тества уебсайта. Можете да намерите IP адреса, на който работи сървърът за тестване, чрез команда.

  • докер инспектира testing_server

Когато тестването е извършено и потвърдено, екипът за въпроси и отговори стартира Job3 и го слива с главния клон. След успешното изграждане на Job3, той автоматично задейства Job1. След това Job1 ще извлече всички файлове от главния клон на GitHub repo и ще го разположи в докер контейнер, т.е. производствения сървър. Така че сега нашият уебсайт е достъпен на производствения сървър за обществено ползване.

Така че това бележи завършването на нашето пътуване за автоматизиране на нашия процес.

Благодаря ти!!