Как да надграждате Дженкинс и да публикувате артефакти чрез ssh с Pipelines

В тази статия искам да споделя моя опит от отдалечено разгръщане на проекти, събрани в Дженкинс и изпратени до инстанцията по SSH протокол. Предполагам, че четенето на написаното по-долу не би интересувало професионалист, но трябва да бъде проверено от DevOps padawan, също като мен :)

Дистанционно управление на сървъра чрез SSH

Така че, ние имаме проект, сглобяване на CI-сървър и трябва да изпратим build или да изпълним определени команди през SSH.

Възможно е да използвате Plugin Publish Over SSH. Позволява да настроите подробности за ssh връзка в интерфейса за настройки на Jenkins. Присвояваме сървър име, адрес, име на потребителя и начин на упълномощаване - чрез парола, парола или указателен ключ. Тези настройки са прости и лесни. Можете да намерите повече подробности на страницата на приставката.

С помощта на този плъгин можете да стартирате команда или да публикувате файлове на всеки етап на сглобяване (можете да видите тези подробности сега в конфигурацията на задачата).

  1. Преди или след началото на сглобяването:

2. По време на сглобяването

3. След сглобяване:

Плъгинът има много допълнителни настройки за копиране на файлове - например създаване на отдалечена папка с печат на времето, папка за изчистване, копиране на файлове и т.н. Предлагам ви да разгледате всички тези опции сами.

тръбопроводи

Що се отнася до мен, беше необходимо (и любопитно) да се подредят нещата с артефакти за публикуване и да се изпълнят над SSH команди в проект на проект на тръбопровода.

Тръбопровод - е начинът на сглобяване на софтуер, разделен на верига от обработващи елементи (етапи), всеки от които може да бъде настроен по-специално.

Предимства на тръбопровода:

1. Възможност за реализация на скриптове, която може да се съхранява в контрола на версията на системата.

2. Проектът може да бъде настроен на пауза, изчакване за разрешения или всяко друго действие за по-нататъшно изпълнение.

3. Възможност за комбиниране на сценични изпълнения, включително тяхното паралелно изпълнение.

Нека го опитаме в действителната практика.

Ще създадем прост проект за тестови тръбопроводи:

Изберете Pipeline скрипт и запишете нашето:

възел {
етап („Подгответе среда“) {
git клон: „развитие“, URL: „git@bitbucket.org: пример / myapp.git“
sh „npm инсталиране“
}
етап („Анализ на код“) {
sh 'ехо "Пусни някои влакна"'
}
етап („Тест на единица“) {
sh "ехо" Тестовете ще се върнат "
}
етап („Създаване“) {
sh 'npm run clean'
sh 'npm run build'
}
}

Проектът има четири етапа: подготовка на околната среда, анализ на статистически код, тестове и само сглобяване.

Подготовка на околната среда

След успешното изпълнение на задача на базата на CI ще получим набор от артефакти, който трябва да бъде публикуван. Ако сте взели под внимание, бихме могли да изпълним всяка скриптирана команда на нашия черупка с инструкция sh „някаква команда“. Ето защо използваме SSH-клиент.

Ако все още не е инсталиран, стартирайте команда sudo apt-get install ssh.

Най-безопасното удостоверяване е входът от ключа, но за такава функция е важно да зададете възможността, налична на сървър. Сега генерирайте ключ за потребителя на Jenkins:

ssh-keygen -t rsa

След това трябва да напишем парола за защита на ключови файлове. Ако ще стартираме SSH скриптове, оставете го празен. Възможно е да промените паролата на ключ чрез команда ssh-keygen. Възстановяването на паролата е невъзможно.

Ключовете се съхраняват в два файла (ако няма друга папка, те могат да бъдат намерени в домашния каталог):

~ / .ssh / id_rsa.pub - отворен ключ. Той се копира на сървъра, където е необходим достъп;

~ / .ssh / id_rsa - затворен ключ. Уверете се, че не го показвате на никого. Все пак, ако това се случи, незабавно генерирайте ключове.

Сега копирайте отворения ни ключ на сървър, където ще публикуваме резултатите от сглобяването. Важното е да се създаде файл в / папка / разрешен_ ключ в папката на потребителя, от когото ще влизаме. Файлът трябва да съдържа всички данни на отворен ключ. Също така трябва да бъдат избрани правилно правата за файлове или ssh не биха го разпознали. Стъпка по стъпка изпълнявайте команди като потребител:

chmod go-w ~ /
chmod 700 ~ / .ssh
chmod 600 ~ / .ssh / разрешени_ ключ

Чрез тези команди ние:

а) отказ на всички, с изключение на собственика, да пишат в домашната директория;

б) четенето, влизането и записването са достъпни само за собственика с настройки .ssh;

в) само собственикът може да чете и запазва промените в file.ssh / оторизирани _ ключове.

За първи път ще влизаме чрез ssh директно от конзолата на CI-сървъра. Ssh винаги пита дали вярваме на ключа или не. Ако отговорът е не, връзката ще бъде затворена. Ако да - ключът ще бъде запазен във файла ~ / .ssh / known_hosts.

Произвеждайки всички необходими настройки, ще можем да стартираме команди на отдалечен сървър без заявка за парола. За да проверите от конзолата, изпълнете командата:

ssh потребител @ сървър ls / var / www /

Трябва да има списък с файлове и поддиректории на / var / www / папка, показани на екрана на отдалечен сървър.

Сега да решим задача за копиране на файлове на отдалечен сървър. Командата scp е най-подходяща, защото прави копие на файл чрез ssh-сесия. Ssh вече предостави команда, така че нищо допълнително не е необходимо за инсталиране.

Синтаксисът на командата е прост: посочваме файл, на кой сървър копираме и начина, по който трябва да се направи:

scp some_file потребител @ сървър: / new / path /

Scp командата позволява да се извърши обратно копиране от отдалечен сървър:

scp потребител @ сървър: / path / remote_file / path / local

Публикуване на артефакти чрез ssh

Сега е време да се върнем към нашия тръбопровод-проект. Научавайки отдалечена работа със ssh сървъра, лесно можем да публикуваме нашите артефакти. Например, нека разгледаме случая, когато проектът ни преминава в папката dist. Копирането ще се извърши чрез интервален каталог:

ssh user @ server rm -rf / var / www / temp_deploy / dist /
ssh потребител @ сървър mkdir -p / var / www / temp_deploy
scp -r dist user @ сървър: / var / www / temp_deploy / dist /
ssh user @ server „rm -rf /var/www/example.com/dist/ && mv / var / www / temp_deploy / dist / /var/www/example.com/“

Добавяме последния етап на разгръщане към нашия проект и получаваме напълно съставен скрипт за доставка на резултати от сървъра за внедряване:

възел {
етап („Подгответе среда“) {
git клон: „развитие“, URL: „git@bitbucket.org: пример / myapp.git“
sh „npm инсталиране“
}
етап („Анализ на код“) {
sh 'ехо "Пусни някои влакна"'
}
етап („Тест на единица“) {
sh "ехо" Тестовете ще се върнат "
}
етап („Създаване“) {
sh 'npm run clean'
sh 'npm run build'
}
етап („Разгръщане“) {
sh 'ssh user @ server rm -rf / var / www / temp_deploy / dist /'
sh „ssh user @ server mkdir -p / var / www / temp_deploy“
sh 'scp -r dist user @ server: / var / www / temp_deploy / dist /'
sh 'ssh user @ server „rm -rf /var/www/example.com/dist/ && mv / var / www / temp_deploy / dist / /var/www/example.com/“
}
}

Тук нашето не толкова дълго пътуване приключи. Разбира се, това не е единственият начин за публикуване на артефакти на сървърите. Има FTP, Windows папки, хранилища (Artifactory, Aptly) и други методи. Толкова добра причина да напишете нещо ново, нали? Както и да е, не се сбогувам :)

от Максим Колесников, DevOps
Дима Дмитриенко, редактор и маркетинг специалист
с помощта на Александър Книга, софтуерен инженер