Усё пачалося з таго, што тымлід адной з нашых каманд распрацоўшчыкаў папрасіў у тэставым рэжыме выставіць вонкі іх новы дадатак, якое напярэдадні было падвергнута кантэйнерызацыі. Я выставіў. Прыкладна праз 20 хвілін паступіла просьба абнавіць дадатак, таму што там дапілавалі вельмі патрэбную штуку. Я абнавіў. Яшчэ праз пару гадзін… ну, вы і так здагадваецеся, што стала адбывацца далей…
Я, прызнацца, даволі гультаяваты (я ж раней у гэтым прызнаваўся? не?), і, улічваючы той факт, што тымліды маюць доступ у Jenkins, у якім у нас увесь CI/CD, падумаў: ды хай ён сам дэплоіць, колькі заманецца ! Успомніў анекдот: дай чалавеку рыбу і ён будзе сыты дзень; назаві чалавека Сыт і ён будзе Сыт усё жыццё. І пайшоў мастрачыць джобу, якая б умела дэплоіць у кубер кантэйнер з дадаткам любой паспяхова сабранай версіі і перадаваць у яго любыя значэння ENV (мой дзядуля, - філолаг, выкладчык ангельскай у мінулым, - цяпер бы пакруціў пальцам у скроні і вельмі выразна паглядзеў бы на мяне, прачытаўшы гэтую прапанову).
Такім чынам, у нататцы я раскажу пра тое, як я навучыўся:
- Дынамічна абнаўляць заданні ў Jenkins'е з самага задання ці з іншых заданняў;
- Падлучацца да хмарнай кансолі (Cloud shell) з ноды з усталяваным агентам Jenkins'а;
- Дэплоіць працоўную нагрузку (workload) у Google Kubernetes Engine.
Насамрэч, я, вядома, некалькі хітрую. Мяркуецца, што хаця б частка інфраструктуры ў вас у гуглавым воблаку, а, такім чынам, вы яго карыстач і, зразумела, у вас ёсць уліковы запіс GCP. Але нататка не аб гэтым.
Гэта чарговая мая шпаргалка. Такія нататкі мне жадаецца пісаць толькі ў адным выпадку: перада мной стаяла задача, я першапачаткова не ведаў, як яе вырашыць, рашэнне не нагуглілася ў гатовым выглядзе, таму я яго гугліў па частках і ў выніку задачу вырашыў. І для таго, каб у будучыні, калі я забудуся, як я гэта зрабіў, мне не прыйшлося зноў усё гугліць па кавалках і кампіляваць разам, я пішу сабе такія шпаргалкі.
Адмова ад адказнасці: 1. Нататка пісалася "для сябе", на ролю лепшая практыка не прэтэндуе. З задавальненнем пачытаю варыянты "а лепш было зрабіць так" у каментарах.
2. Калі прыкладную частку нататкі лічыць соллю, то, як і ўсе мае папярэднія нататкі, гэтая — слабасолевы раствор.
Дынамічнае абнаўленне настроек заданняў у Jenkins
Прадбачу ваша пытанне: а пры чым тут наогул дынамічнае абнаўленне джобы? Упісаў ручкамі значэнне радковага параметра і наперад!
Адказваю: я праўда лянівы, не кахаю, калі жаляцца: Міша, дэплой фарбуецца, усё знікла! Пачынаеш глядзець, а там памылка друку ў значэнні якога-небудзь параметру запуску задання. Таму аддаю перавагу ўсё рабіць максімальна фулпруфна. Калі ёсць магчымасць пазбавіць карыстальніка магчымасці ўводзіць дадзеныя напрамую, даўшы замест гэтага спіс значэнняў для выбару, то я арганізоўваю выбар.
План такі: ствараем заданне ў Jenkins, у якім перад запускам можна было б з спісу абраць версію, пазначыць значэнні для параметраў, якія перадаюцца ў кантэйнер праз ENV, далей яно збірае кантэйнер і пушае яго ў Container Registry. Далей адтуль кантэйнер запускаецца ў куберы як нагрузка з параметрамі, зададзенымі ў джобе.
Працэс стварэння і налады задання ў Jenkins'е разглядаць не будзем, гэта афтопік. Будзем зыходзіць з таго, што заданне гатова. Для рэалізацыі спісу з версіямі, які абнаўляецца, нам патрэбныя дзве рэчы: ужо існуючы спіс-крыніца з апрыёры валіднымі нумарамі версій і пераменная тыпу Choice parameter у заданні. У нашым прыкладзе няхай пераменная будзе насіць імя BUILD_VERSION, на ёй спыняцца падрабязна не будзем. А вось на спісе-крыніцы давайце спынімся падрабязней.
Варыянтаў не такое ўжо і мноства. Мне адразу ў галаву прыйшлі два:
- Выкарыстоўваць Remote access API, які прапануе Jenkins сваім карыстальнікам;
- Запытваць змесціва выдаленай тэчкі рэпазітара (у нашым выпадку гэта JFrog Artifactory, што не прынцыпова).
Jenkins Remote access API
Па якая склалася выдатнай традыцыі ўпадабаю пазбегнуць вялізных тлумачэнняў.
Дазволю сабе толькі вольны пераклад кавалка першага абзаца :
Jenkins падае API для выдаленага машынна-зразумелага доступу да свайго функцыяналу. <…> Выдалены доступ прапануецца ў REST'ападобным стылі. Гэта азначае, што адсутнічае адзіная кропка ўваходу да ўсіх магчымасцяў, а замест яе выкарыстоўваецца URL выгляду "…/api/", дзе"..."Азначае аб'ект, да якога прымяняюцца магчымасці API."
Іншымі словамі, калі заданне на дэплой, аб якім мы ў дадзены момант гаворым, даступна па адрасе http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build, то API-свістулькі для гэтага задання даступныя па адрасе http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build/api/
Далей у нас ёсць выбар, у якім выглядзе атрымліваць выснову. Спынімся на XML, паколькі API толькі ў гэтым выпадку дазваляе выкарыстоўваць фільтраванне.
Давайце проста так паспрабуем атрымаць спіс усіх запускаў задання. Нас цікавіць толькі імя зборкі (displayName) і яе вынік (вынік):
http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build/api/xml?tree=allBuilds[displayName,result]Атрымалася?
Цяпер адфільтруем толькі тыя запускі, якія ў выніку з вынікам Поспех. Выкарыстоўваны аргумент &exclude і ў якасці параметру перадамо яму шлях да значэння не роўнага Поспех. Так так. Падвойнае адмаўленне - гэта сцвярджэнне. Выключаем усё тое, што нас не цікавіць:
http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build/api/xml?tree=allBuilds[displayName,result]&exclude=freeStyleProject/allBuild[result!='SUCCESS'] Скрыншот спісу паспяховых
Ну і проста для пястоты пераканаемся, што фільтр нас не падмануў (фільтры ж ніколі не хлусяць!) і вывядзем спіс «не-паспяховых»:
http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build/api/xml?tree=allBuilds[displayName,result]&exclude=freeStyleProject/allBuild[result='SUCCESS'] Скрыншот спісу не-паспяховых
Спіс версій з тэчкі на выдаленым серверы
Ёсць і другі спосаб атрымаць спіс версій. Ён мне падабаецца нават больш, чым зварот да API Jenkins'а. Ну, таму што калі дадатак паспяхова сабралася, значыць яго спакавалі і паклалі ў рэпазітар у адпаведную тэчку. Тыпу, рэпазітар гэта па змаўчанні сховішча працоўных версій прыкладанняў. Тыпу. Ну вось і спытаем у яго, якія версіі на захоўванні. Выдаленую тэчку будзем curl'іць, grep'аць і awk'аць. Калі камусьці цікавы ўанлайнер, то ён пад спойлерам.
Каманда адным радком
Звярніце ўвагу на дзве рэчы: я перадаю ў загалоўку рэквізіты для падключэння і мне не патрэбныя прама ўвогуле ўсе версіі з папкі, і я адбіраю толькі тыя, што былі створаны на працягу месяца. Адрэдагуйце каманду ў адпаведнасці з вашымі рэаліямі і патрэбамі:
curl -H "X-JFrog-Art-Api:VeryLongAPIKey" -s http://arts.myre.po/artifactory/awesomeapp/ | sed 's/a href=//' | grep "$(date +%b)-$(date +%Y)|$(date +%b --date='-1 month')-$(date +%Y)" | awk '{print $1}' | grep -oP '>K[^/]+' )Настройка заданняў і файл канфігурацыі задання ў Jenkins
З крыніцай спісу версій разабраліся. Давайце зараз атрыманы спіс укруцім у заданне. Для мяне відавочным рашэннем было дадаць крок у заданні па зборцы дадатку. Крок, які б выконваўся ў выпадку выніку "поспех".
Адкрываем наладкі задання на зборку і скролім у самы ніз. Ціснем на кнопачкі: Add build step -> Conditional step (single). У наладах кроку выбіраемы ўмова Current build status, выстаўляемы значэнне Поспех, якое выконваецца дзеянне ў выпадку поспеху Run shell command.
І зараз самае цікавае. Канфігурацыі заданняў Jenkins захоўвае ў файлах. У фармаце XML. Па шляху http://путь-до-задания/config.xml Адпаведна, можна спампаваць файл з канфігурацыяй, адрэдагаваць яго патрэбнай выявай і пакласці на месца, адкуль узялі.
Памятайце, вышэй мы дамовіліся, што для спісу версій створым параметр BUILD_VERSION?
Давайце спампуем файл канфігурацыі і зазірнем унутр яго. Проста каб пераканацца, што параметр на месцы і сапраўды патрэбнага віду.
Скрыншот пад спойлерам.
У вас прыведзены фрагмент config.xml павінен выглядаць гэтак жа. За тым выключэннем, што змест элемента choices пакуль што адсутнічае
Пераканаліся? Ну ўсё, пішам скрыпт, які будзе выконвацца ў выпадку паспяховай зборкі.
Скрыпт будзе атрымліваць спіс версій, спампоўваць файл канфігурацыі, пісаць у яго ў патрэбнае нам месца спіс версій, а потым класці яго назад. Так. Усё дакладна. Пісаць спіс версій у XML'ку ў тое месца, дзе ўжо ёсць спіс версій (будзе ў будучыні, пасля першага запуску скрыпту). Я ведаю, у свеце яшчэ жывуць лютыя аматары рэгулярных выразаў. Я да іх не стаўлюся. Усталюйце, калі ласка, на тую машыну, дзе будзе рэдагавацца канфіг. Мне здаецца, гэта не такі ўжо і вялікі поплатак за тое, каб пазбегнуць рэдагаванні XML з дапамогай sed'а.
Пад спойлерам прыводжу код, які выконвае вышэйапісаную паслядоўнасць цалкам.
Пішам у канфіг спіс версій з тэчкі на выдаленым серверы
#!/bin/bash
############## Скачиваем конфиг
curl -X GET -u username:apiKey http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_k8s/config.xml -o appConfig.xml
############## Удаляем и заново создаем xml-элемент для списка версий
xmlstarlet ed --inplace -d '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]/a[@class="string-array"]' appConfig.xml
xmlstarlet ed --inplace --subnode '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]' --type elem -n a appConfig.xml
xmlstarlet ed --inplace --insert '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]/a' --type attr -n class -v string-array appConfig.xml
############## Читаем в массив список версий из репозитория
readarray -t vers < <( curl -H "X-JFrog-Art-Api:Api:VeryLongAPIKey" -s http://arts.myre.po/artifactory/awesomeapp/ | sed 's/a href=//' | grep "$(date +%b)-$(date +%Y)|$(date +%b --date='-1 month')-$(date +%Y)" | awk '{print $1}' | grep -oP '>K[^/]+' )
############## Пишем массив элемент за элементом в конфиг
printf '%sn' "${vers[@]}" | sort -r |
while IFS= read -r line
do
xmlstarlet ed --inplace --subnode '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]/a[@class="string-array"]' --type elem -n string -v "$line" appConfig.xml
done
############## Кладем конфиг взад
curl -X POST -u username:apiKey http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_k8s/config.xml --data-binary @appConfig.xml
############## Приводим рабочее место в порядок
rm -f appConfig.xmlКалі вам больш спадабаўся варыянт з атрыманнем версій з Jenkins'а і вы гэтак жа гультаяватыя, як я, то пад спойлерам той жа самы код, але спіс з Jenkins'а:
Пішам у канфіг спіс версій з Jenkins'а
Толькі ўлічыце момант: у мяне імя зборкі складаецца з парадкавага нумара і нумары версіі, падзеленых двукроп'ем. Адпаведна, awk адразае непатрэбную частку. Для сябе гэты радок зменіце пад вашыя патрэбы.
#!/bin/bash
############## Скачиваем конфиг
curl -X GET -u username:apiKey http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_k8s/config.xml -o appConfig.xml
############## Удаляем и заново создаем xml-элемент для списка версий
xmlstarlet ed --inplace -d '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]/a[@class="string-array"]' appConfig.xml
xmlstarlet ed --inplace --subnode '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]' --type elem -n a appConfig.xml
xmlstarlet ed --inplace --insert '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]/a' --type attr -n class -v string-array appConfig.xml
############## Пишем в файл список версий из Jenkins
curl -g -X GET -u username:apiKey 'http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build/api/xml?tree=allBuilds[displayName,result]&exclude=freeStyleProject/allBuild[result!=%22SUCCESS%22]&pretty=true' -o builds.xml
############## Читаем в массив список версий из XML
readarray vers < <(xmlstarlet sel -t -v "freeStyleProject/allBuild/displayName" builds.xml | awk -F":" '{print $2}')
############## Пишем массив элемент за элементом в конфиг
printf '%sn' "${vers[@]}" | sort -r |
while IFS= read -r line
do
xmlstarlet ed --inplace --subnode '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]/a[@class="string-array"]' --type elem -n string -v "$line" appConfig.xml
done
############## Кладем конфиг взад
curl -X POST -u username:apiKey http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_k8s/config.xml --data-binary @appConfig.xml
############## Приводим рабочее место в порядок
rm -f appConfig.xmlПа ідэі, калі вы пратэставалі код, напісаны на аснове прыкладаў вышэй, то ў заданні на дэплой у вас ужо павінен з'явіцца выпадальны спіс з версіямі. Вось прыкладна як на скрыншоце пад спойлерам.
Карэктна запоўнены спіс версій
Калі ўсё адпрацавала, то копіпасціце скрыпт у Run shell command і захоўвайце змены.
Падключэнне да Cloud shell
Зборшчыкі ў нас у кантэйнерах. У якасці сродку дастаўкі прыкладанняў і мэнэджэра канфігурацый мы выкарыстоўваем Ansible. Адпаведна, калі гаворка заходзіць аб зборцы кантэйнераў, варыянтаў у галаву прыходзіць тры: усталяваць Docker у Docker'е, усталяваць Docker на машыну з Ansible'ом, альбо збіраць кантэйнеры ў хмарнай кансолі. Пра плягіны для Jenkins мы дамовіліся ў гэтай нататцы маўчаць. Памятаеце?
Я вырашыў: ну, раз кантэйнеры «са скрынкі» можна збіраць у хмарнай кансолі, то навошта гарадзіць агарод? Keep it clean, праўда? Жадаю збіраць кантэйнеры Jenkins'ом у хмарнай кансолі, а потым адтуль жа куляць іх у кубер. Тым больш, што ўнутры інфраструктуры ў гугла ну вельмі тлустыя каналы, што спрыяльна адаб'ецца на хуткасці дэплою.
Для падлучэння да хмарнай кансолі неабходны дзве рэчы: gcloud і правы доступу да API Google Cloud для таго экзэмпляра ВМ, з якой будзе гэта самае падключэнне ажыццяўляцца.
Для тых, хто плануе падлучацца наогул не з гуглавага аблокі
Google дапускае магчымасць адключэння інтэрактыўнай аўтарызацыі ў сваіх сэрвісах. Гэта дазволіць падлучацца да кансолі хоць з кофемашіны, калі яна пад *nix'амі і ў яе самой ёсць кансоль.
Калі ёсць патрэба ў тым, каб я асвятліў гэтае пытанне падрабязней у рамках гэтай нататкі - пішыце ў каментарах. Набярэцца дастатковая колькасць галасоў - напішу апдэйт па гэтай тэме.
Найпросты спосаб даць правы - праз вэб-інтэрфейс.
- Спыніце асобнік ВМ, з якога ў далейшым будзе выконвацца падлучэнне да хмарнай кансолі.
- Адкрыйце Звесткі экзэмпляра і націсніце Змяніць.
- У самым нізе старонкі абярыце вобласць дзеяння доступу асобніка Поўны доступ да ўсіх Cloud API.
Скрыншот
- Захавайце змены і запусціце асобнік.
Па канчатку загрузкі ВМ, падключыцеся да яе па SSH і пераканаецеся, што падлучэнне адбываецца без памылкі. Скарыстайцеся камандай:
gcloud alpha cloud-shell ssh Паспяховае падлучэнне выглядае прыкладна так
Дэплой у GKE
Паколькі мы ўсяляк імкнемся цалкам перайсці на IaC (Infrastucture as a Code), докерфайлы ў нас захоўваюцца ў гіце. Гэта з аднаго боку. А дэплой у kubernetes апісваецца yaml-файлам, які выкарыстоўваецца толькі дадзеным заданнем, які сам па сабе таксама як бы код. Гэта з іншага боку. Увогуле, я да таго, што план такі:
- Бярэм значэння зменных BUILD_VERSION і, апцыянальна, значэнні зменных, якія будуць перададзены праз ENV.
- Качаем з гіта докерфайл.
- Які генеруецца yaml для дэплою.
- Заліваем абодва гэтых файла па scp у хмарную кансоль.
- Білдзім там кантэйнер і пушаем яго ў Container registry
- Ужывальны файл дэплою нагрузкі ў кубер.
Давайце больш канкрэтна. Раз загаварылі аб ENV, то выкажам здагадку, нам трэба будзе перадаваць значэнні двух параметраў: ПАРАМЕТР1 и ПАРАМЕТР2. Дадаем іх заданне на дэплой, тып String Parameter.
Скрыншот
Генераваць yaml будзем простым перанакіраваннем сумаваць у файл. Мяркуюцца, зразумела, што ў докерфайле ў вас прысутнічаюць ПАРАМЕТР1 и ПАРАМЕТР2, што імя нагрузкі будзе awesomeapp, а сабраны кантэйнер з дадаткам названай версіі ляжыць у Container registry па шляху gcr.io/awesomeapp/awesomeapp-$BUILD_VERSION, Дзе $BUILD_VERSION якраз і быў абраны з выпадальнага спісу.
Лістынг каманд
touch deploy.yaml
echo "apiVersion: apps/v1" >> deploy.yaml
echo "kind: Deployment" >> deploy.yaml
echo "metadata:" >> deploy.yaml
echo " name: awesomeapp" >> deploy.yaml
echo "spec:" >> deploy.yaml
echo " replicas: 1" >> deploy.yaml
echo " selector:" >> deploy.yaml
echo " matchLabels:" >> deploy.yaml
echo " run: awesomeapp" >> deploy.yaml
echo " template:" >> deploy.yaml
echo " metadata:" >> deploy.yaml
echo " labels:" >> deploy.yaml
echo " run: awesomeapp" >> deploy.yaml
echo " spec:" >> deploy.yaml
echo " containers:" >> deploy.yaml
echo " - name: awesomeapp" >> deploy.yaml
echo " image: gcr.io/awesomeapp/awesomeapp-$BUILD_VERSION:latest" >> deploy.yaml
echo " env:" >> deploy.yaml
echo " - name: PARAM1" >> deploy.yaml
echo " value: $PARAM1" >> deploy.yaml
echo " - name: PARAM2" >> deploy.yaml
echo " value: $PARAM2" >> deploy.yamlАгенту Jenkins'а пасля падлучэння з дапамогай gcloud alpha cloud-shell ssh інтэрактыўны рэжым не даступны, таму перадаем каманды ў хмарную кансоль з дапамогай параметру -command.
Які чысціцца хатнюю тэчку ў хмарнай кансолі ад старога докерфайла:
gcloud alpha cloud-shell ssh --command="rm -f Dockerfile"Кладзём свежапампаваны докерфайл у хатнюю тэчку хмарнай кансолі з дапамогай scp:
gcloud alpha cloud-shell scp localhost:./Dockerfile cloudshell:~Збіраны, тегуем і пушаем кантэйнер у Container registry:
gcloud alpha cloud-shell ssh --command="docker build -t awesomeapp-$BUILD_VERSION ./ --build-arg BUILD_VERSION=$BUILD_VERSION --no-cache"
gcloud alpha cloud-shell ssh --command="docker tag awesomeapp-$BUILD_VERSION gcr.io/awesomeapp/awesomeapp-$BUILD_VERSION"
gcloud alpha cloud-shell ssh --command="docker push gcr.io/awesomeapp/awesomeapp-$BUILD_VERSION"
Аналагічнай выявай паступаем з файлам дэплою. Звярніце ўвагі, што ў камандах ніжэй выкарыстоўваюцца выдуманыя імёны кластара, куды адбываецца дэплой (awsm-cluster) і імя праекта (awesome-project), дзе знаходзіцца кластар.
gcloud alpha cloud-shell ssh --command="rm -f deploy.yaml"
gcloud alpha cloud-shell scp localhost:./deploy.yaml cloudshell:~
gcloud alpha cloud-shell ssh --command="gcloud container clusters get-credentials awsm-cluster --zone us-central1-c --project awesome-project &&
kubectl apply -f deploy.yaml"Запускаем заданне, адчыняны выснова кансолі і спадзяемся ўбачыць паспяховую зборку кантэйнера.
Скрыншот
А далей і паспяховы дэплой сабранага кантэйнера
Скрыншот
Я наўмысна абышоў увагай наладу Уваход. Па адной простай прычыне: аднойчы настроіўшы яго на нагрузка з зададзеным імем, ён застанецца працаздольным, колькі дэплояў з гэтым імем не праводзь. Ну і наогул, гэта крыху за рамкамі гісторыі.
замест высноў
Усе прыведзеныя вышэй крокі, мусіць, можна было не рабіць, а проста ўсталяваць якую-небудзь плягін для Jenkins'а, іх мууульён. Але я чамусьці не люблю плагіны. Ну, дакладней, звяртаюся да іх толькі ад безвыходнасці.
А яшчэ мне проста падабаецца раскалупаць якую-небудзь новую для мяне тэму. Тэкст вышэй - у тым ліку і спосаб падзяліцца знаходкамі, якія я зрабіў, вырашаючы апісаную ў самым пачатку задачу. Падзяліцца з тымі, хто, як і, зусім не люты воўк у дэвапсе. Калі хаця б камусьці мае знаходкі дапамогуць — буду задаволены.
Крыніца: habr.com