ci/cd

CI\CD АВТОМАТИЗАЦИЯ С JENKINS

Thank you for reading this post, don't forget to subscribe!

В дан­ной ста­тье мы рас­смот­рим про­цес­сы CI\CD автоматизации.

Раз­бе­рем роль тако­го про­дук­та, как Jenkins и его ана­ло­гов. Про­грамм­ное обес­пе­че­ние Jenkins напи­са­но на язы­ке про­грам­ми­ро­ва­ния Java, по отзы­вам ИТ сооб­ще­ства, дан­ный про­дукт напи­сан очень хоро­шо. Но самое глав­ное дан­ное про­грамм­ное обес­пе­че­ние пол­но­стью бес­плат­ное. Мно­гие энту­зи­а­сты в мире для дан­но­го про­дук­та пишут пла­ги­ны, кото­рые рас­ши­ря­ют функ­ци­о­нал Jenkins.

Рас­смот­рим 2 клю­че­вых поня­тия CI\CD Автоматизации.

CI – Continuous Integration. Это DevOps модель, в кото­рой раз­ра­бот­чи­ки дела­ют commit кода в репо­зи­то­рий (обыч­но исполь­зу­ет­ся github или gitlab, для хра­не­ния кода) и авто­ма­ти­че­ски запус­ка­ет­ся build или ком­пи­ля­ция это­го кода, после это­го запус­ка­ют­ся авто­ма­ти­че­ские тесты кода: Unit Test, Integration Test, Functionality Test.

CD – Continuous Delivery and Deployment. Это DevOps модель, в кото­рой раз­ра­бот­чи­ки дела­ют commit кода в репо­зи­то­рий и авто­ма­ти­че­ски запус­ка­ет­ся build или ком­пи­ля­ция это­го кода, после это­го запус­ка­ют­ся авто­ма­ти­че­ские тесты кода и гото­вый Artifact (ском­пи­ли­ро­ван­ный код, напри­мер если это Java, то арте­фак­том явля­ет­ся var, если это Android при­ло­же­ние, то apk файл) дела­ет деп­лой в Staging и Production, т.е про­ис­хо­дит уста­нов­ка кода в раз­вер­ну­тую вашу сре­ду в необ­хо­ди­мом кон­ту­ре. Рас­смот­рим про­цесс на примере.

ПРОЦЕСС CI\CD АВТОМАТИЗАЦИИ

Пер­вым шагом в про­цес­се явля­ет­ся Commit to Source Control (github, gitlab или bitbucket), систе­ма опре­де­ля­ет нали­чие ново­го кода, сра­ба­ты­ва­ет триг­гер и авто­ма­ти­че­ски запус­ка­ет­ся сле­ду­ю­щий этап Build\Compile - ком­пи­ля­ция кода.

Систе­ма ска­чи­ва­ет новый код, напри­мер, если код попал в master branch (основ­ную вет­ку). После полу­че­ния отве­та от сбор­ки, что все про­шло успеш­но, запус­ка­ет­ся сле­ду­ю­щий этап тестов. Все тесты пишут все те же про­грам­ми­сты, для того, что­бы про­ве­рить на сколь­ко кор­рект­но отра­бо­тал код. Весь этот про­цесс назы­ва­ет­ся Continuous Integration. Это клас­си­че­ская схе­ма содер­жит 3 эта­па, ино­гда вклю­ча­ют­ся допол­ни­тель­ные шаги, но они не прин­ци­пи­аль­ны. В резуль­та­те дан­но­го про­цес­са мы полу­ча­ем ском­пи­ли­ро­ван­ный и про­те­сти­ро­ван­ный код.

Давай­те рас­смот­рим после­ду­ю­щие шаги. Сле­ду­ю­щий шаг мы можем сде­лать deployment кода. По сути это тот же про­цесс копи­ро­ва­ния фай­лов кода на сер­ве­ра. Про­цесс деп­лоя мож­но делать в раз­ные места, мож­но делать в AWS или Azure, мож­но делать в свое част­ное обла­ко, раз­вер­ну­тое на VMware. Весь про­цесс с доба­воч­ны­ми шага­ми назы­ва­ет­ся Continuous Delivery and Deployment.

Полу­ча­ет­ся сле­ду­ю­щее: за Source Control – отве­ча­ет git. За шаг build и compile будет отве­чать Jenkins. Сле­до­ва­тель­но, Jenkins запу­стит­ся, когда кто-нибудь сде­ла­ет комит в систе­му кон­тро­ля вер­сий, в основ­ную вет­ку или не основ­ную, смот­ря как настро­е­но. Сле­ду­ю­щим шагом Jenkins выпол­нит все необ­хо­ди­мые тесты, кото­рые под­го­то­ви­ли про­грам­ми­сты. Сле­ду­ю­щий шаг Deploy так же запу­стит Jenkins и ско­пи­ру­ет код на необ­хо­ди­мые сер­ве­ра, с помо­щью скрип­та или scp если это Linux сер­вер. Суще­ству­ют вари­а­ции с исполь­зо­ва­ни­ем Puppet или Ansible если мы дела­ем Deploy арте­фак­та или кон­фи­гу­ра­ции в целом.

Суще­ству­ют аль­тер­на­ти­вы Jenkins, напри­мер, Bamboo, Circleci, Gitlab CI\CD, TeamCity.

УСТАНОВКА JENKINS

Для раз­вер­ты­ва­ния Jenkins нам пона­до­бит­ся вир­ту­аль­ная маши­на на Ubuntu вер­сии 18 или выше.

Идем на офи­ци­аль­ный сайт Jenkins,в раз­де­ле Download мы можем уви­деть 2 вер­сии. На момент напи­са­нии ста­тьи акту­аль­ная вер­сия Jenkins 2.319.2LTS и во вто­рой колон­ке мы можем уви­деть недель­ные вер­сии Jenkins 2.333

Как види­те дис­три­бу­ти­вы есть прак­ти­че­ски под все опе­ра­ци­он­ные систе­мы. Мы будем исполь­зо­вать ста­биль­ную вер­сию под Ubuntu\Debian. Озна­ко­мим­ся с тре­бо­ва­ни­я­ми к уста­нов­ке про­дук­та Jenkins. Для инстал­ля­ции потре­бу­ет­ся мини­мум 256 МБ RAM, места 1 ГБ, а так­же на сай­те напи­са­ны реко­мен­до­ван­ные тре­бо­ва­ния, с кото­ры­ми будет доста­точ­но ком­форт­но рабо­тать с продуктом.

Так как Jenkins напи­сан на Java, то для запус­ка и рабо­ты потре­бу­ет­ся непо­сред­ствен­но уста­нов­лен­ная на сер­ве­ре Java. Для нача­ла про­ве­рим вер­сию java на сервере.

java –version

Если сер­вер све­жий или Java не уста­нов­ле­на, то опе­ра­ци­он­ная систе­ма сооб­щит, что такая коман­да не най­де­на и пред­ло­жить уста­но­вить Java. Java уста­нав­ли­ва­ет­ся доста­точ­но просто:

  • sudo apt update – oбнов­ля­ем репозиторий
  • sudo apt search openjdk – ищем необ­хо­ди­мый пакет
  • sudo apt install openjdk-11-jdk – запус­ка­ем уста­нов­ку java в про­цес­се систе­ма попро­сит под­твер­дить. Что­бы пре­ду­пре­жде­ние не выско­чи­ло мы можем запу­стить уста­нов­ку с клю­чем –y

По окон­ча­нию уста­нов­ки мы опять про­ве­ря­ем вер­сию. Систе­ма пока­жет вер­сию и билд Java. Теперь наш сер­вер готов к нача­лу уста­нов­ки Jenkins.

Добав­ля­ем ключ и репо­зи­то­рий в опе­ра­ци­он­ную систему:

  • sudo apt-get update – обнов­ля­ем репозиторий
  • sudo apt-get install Jenkins – инстал­ли­ру­ем непо­сред­ствен­но сам Jenkins

Теперь мы можем сде­лать пост настро­еч­ные меро­при­я­тия непо­сред­ствен­но в Jenkins.

Откры­ва­ем бра­у­зер и пере­хо­дим на веб интер­фейс http://ipaddr:8080, где вме­сто ipaddr – под­став­ля­ем IP адрес сер­ве­ра. В ответ полу­ча­ем вот такое сооб­ще­ние - Unlock Jenkins

Систе­ма про­сит вве­сти допол­ни­тель­ный ключ, кото­рый был сге­не­ри­ро­ван при уста­нов­ке сер­ве­ра. Най­ти его доста­точ­но про­сто доста­точ­но вве­сти в кон­со­ли сервера

sudo cat /var/lib/jenkins/secrets/initialAdminPassword

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

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

Выби­ра­ем стан­дарт­ную уста­нов­ку и начи­на­ет­ся про­цесс настрой­ки само­го Jenkins.

Мы можем видать, что ста­вит­ся git пла­гин, LDAP для рабо­ты с Active Directory, ssh для вза­и­мо­дей­ствия по про­то­ко­лу ssh, рас­ши­ре­ние E-mail для отправ­ки уве­дом­ле­ний и.т.д

После непро­дол­жи­тель­но­го ожи­да­ния, систе­ма пред­ла­га­ет создать супер­поль­зо­ва­те­ля с пра­ва­ми адми­ни­стра­то­ра в системе.

Запол­не­ние не слож­ное. Если бы мы выбра­ли дру­гой вари­ант уста­нов­ки, то систе­ма нам пред­ло­жи­ла бы выбрать само­сто­я­тель­но нуж­ные плагины.

При­мер­но вот в такой фор­ме. Фор­ма от вер­сии к вер­сии может отличатся.

По окон­ча­нию запол­не­ния фор­мы, попа­да­ем на экран где нам пред­ла­га­ют про­ве­рить URL, т.к эти дан­ные будет Jenkins исполь­зо­вать, как пере­мен­ные среды.

В ито­ге мы попа­да­ем на глав­ный экран Jenkins. Дан­ный экран – это основ­ной рабо­чий стол. С помо­щью пла­ги­нов его мож­но касто­ми­зи­ро­вать. Так же мож­но в джо­бы доба­вить мно­го раз­ных параметров.