Деплой на Docker Swarm

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

deploy

Начи­ная с вер­сии 3. docker-compose

Груп­па настро­ек, посвя­щен­ная деп­лою и запус­ку сер­ви­сов. Ука­зан­ные в дан­ной груп­пе настрой­ки исполь­зу­ют­ся толь­ко при деп­лое на swarm исполь­зуя docker stack deploy, и игно­ри­ру­ет­ся при исполь­зо­ва­нии команд docker-compose up и docker-compose run.

[codesyntax lang="php" blockstate="collapsed"]

[/codesyntax]

 

Доступ­ны сле­ду­ю­щие допол­ни­тель­ные опции:

endpoint_mode

Исполь­зу­е­мый метод обна­ру­же­ния (“service discovery”) для внеш­них запро­сов от клиентов.

Начи­ная с вер­сии 3.3. docker-compose

  • endpoint_mode: vip - Докер при­сва­и­ва­ет сер­ви­су вир­ту­аль­ный IP адрес (VIP), кото­рый высту­па­ет в роли “внеш­не­го” для полу­че­ния досту­па к сер­ви­су. Докер сам зани­ма­ет­ся марш­ру­ти­за­ци­ей запро­сов меж­ду кли­ен­том и доступ­ным вор­ке­ром (на кото­ром кру­тит­ся сер­вис), при этом кли­ент ниче­го не зна­ет ни о коли­че­стве нод, ни о их IP и пор­тах (исполь­зу­ет­ся по умолчанию).
  • endpoint_mode: dnsrr - DNS “round-robin” (DNSRRне исполь­зу­ет оди­ноч­ный вир­ту­аль­ный IP адрес. Докер уста­нав­ли­ва­ет DNS запи­си для сер­ви­са таким обра­зом, что когда кли­ент его запра­ши­ва­ет - ему воз­вра­ща­ет­ся спи­сок из IP адре­сов, и кли­ент сам под­клю­ча­ет­ся к одно­му из них. DNS “round-robin” поле­зен в слу­ча­ях исполь­зо­ва­ния сво­е­го соб­ствен­но­го балан­си­ров­щи­ка нагруз­ки, или для гибрид­ных Windows & Linux приложений.

[codesyntax lang="php" blockstate="collapsed"]

[/codesyntax]

 

endpoint_mode так же мож­но исполь­зо­вать как флаг запус­ка при исполь­зо­ва­нии кон­со­ли docker service create.

Спи­сок всех swarm-команд досту­пен по этой ссыл­ке.

Если вы хоти­те узнать боль­ше о “service discovery” и сетях в swarm-режи­ме, перей­ди­те в раз­дел настрой­ки service discovery.

labels

Уста­нов­ка ярлы­ков (labels) сер­ви­са. Эти ярлы­ки при­сва­и­ва­ют­ся толь­ко само­му сер­ви­су, а некако­му-либо кон­тей­не­ру это­го сервиса.

[codesyntax lang="php" blockstate="collapsed"]

[/codesyntax]

 

Для уста­нов­ки ярлы­ков (labels) для кон­тей­не­ров (а не сер­ви­са), исполь­зуй­те ключ labels вне сек­ции deploy:

[codesyntax lang="php" blockstate="collapsed"]

[/codesyntax]

 

mode

Может быть гло­баль­ным (global, стро­го один кон­тей­нер на swarm-ноде) или реп­ли­ци­ро­ван­ным(replicated, с ука­за­ни­ем коли­че­ства кон­тей­не­ров). По умол­ча­нию исполь­зу­ет­ся replicated. Подроб­нее мож­но про­чи­тать в раз­де­ле Реп­ли­ци­ро­ван­ные и гло­баль­ные сер­ви­сы.

[codesyntax lang="php" blockstate="collapsed"]

[/codesyntax]

 

placement

Ука­за­ние мест раз­ме­ще­ния кон­тей­не­ров и их “пред­по­чте­ний”. Наи­бо­лее пол­ное опи­са­ние допу­сти­мых опций вы смо­же­те най­ти в раз­де­лах “constraints” и “preferences” соот­вет­ствен­но.

[codesyntax lang="php" blockstate="collapsed"]

[/codesyntax]

 

replicas

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

[codesyntax lang="php" blockstate="collapsed"]

[/codesyntax]

 

resources

Настрой­ка огра­ни­че­ний исполь­зу­е­мых ресурсов

При­ме­ча­ние: Ука­зан­ные в дан­ной сек­ции опции пере­кры­ва­ют более ста­рые огра­ни­че­ния и опции, что ука­за­ны в Compose-фай­ле для не-swarm режи­ма до вер­сии 3 (cpu_sharescpu_quotacpusetmem_limitmemswap_limitmem_swappiness), как опи­са­но в раз­де­ле обнов­ле­ние с вер­сии 2.x до 3.x.

Каж­дое зна­че­ние, ука­зан­ное в дан­ной сек­ции, явля­ет­ся ана­ло­гом опций для docker service create.

В при­ве­ден­ном ниже при­ме­ре сер­вис redis может исполь­зо­вать не более 50 Мб памя­ти и 0.50 (50%) доступ­но­го про­цес­сор­но­го вре­ме­ни (CPU), а так же име­ет заре­зер­ви­ро­ван­ные 20 Мб памя­ти и 0.25CPU (все­гда доступ­ные для него).

[codesyntax lang="php" blockstate="collapsed"]

[/codesyntax]

 

Настрой­ка огра­ни­че­ний ресур­сов для не-swarm режи­ма доступ­на в этом раз­де­ле. Если у вас воз­ник­нут допол­ни­тель­ные вопро­сы - обра­ти­те вни­ма­ние на этот топик на github.com.

Исключения класса “Out Of Memory” (OOME)

Если ваши сер­ви­сы или кон­тей­не­ры попы­та­ют­ся исполь­зо­вать объ­ём памя­ти боль­ше, чем досту­пен на исполь­зу­е­мой систе­ме, вы рис­ку­е­те “пой­мать” исклю­че­ние клас­са “Out Of Memory Exception” (OOME) и кон­тей­нер, или сам докер-демон может быть при­бит демо­ном ядра систе­мы (“kernel OOM killer”). Во избе­жа­ние это­го убе­ди­тесь в нали­чии доступ­ных ресур­сов на целе­вой систе­ме и озна­ком­тесь с раз­де­лом пони­ма­ние рис­ков недо­стат­ка доступ­ной памя­ти.

restart_policy

Ука­зы­ва­ет как и в каких слу­ча­ях необ­хо­ди­мо пере­за­пус­кать кон­тей­не­ры когда они оста­нав­ли­ва­ют­ся. Заме­на сек­ции restart.

  • condition (усло­вие): одно из воз­мож­ных зна­че­ний - none (нико­гда), on-failure (при ошиб­ке) или any (все­гда) (по умол­ча­нию: any).
  • delay (задерж­ка): Задерж­ка меж­ду попыт­ка­ми пере­за­пус­ка, ука­зы­ва­ет­ся в фор­ма­те “про­дол­жи­тель­ность” (по умол­ча­нию: 0).
  • max_attempts: Коли­че­ство пред­при­ни­ма­е­мых попы­ток пере­за­пус­ка перед тем, как пре­кра­тить пытать­ся запу­стить кон­тей­нер (по умол­ча­нию: коли­че­ство попы­ток не огра­ни­че­но). Если кон­тей­нер не запу­стил­ся в пре­де­лах ука­зан­но­го “окна” (window), эта попыт­ка не учи­ты­ва­ет­ся при рас­че­те зна­че­ния max_attempts. Напри­мер, если max_attempts уста­нов­лен рав­ным 2, и пере­за­пуск завер­шил­ся ошиб­кой при пер­вой попыт­ке, может быть пред­при­ня­то более двух попы­ток перезапуска.
  • window: Задерж­ка перед при­ня­ти­ем реше­ния о том, что пере­за­пуск успеш­но завер­шил­ся. Ука­зы­ва­ет­ся в фор­ма­те “про­дол­жи­тель­ность” (по умол­ча­нию: задерж­ка отсутствует).

Для луч­ше­го пони­ма­ния луч­ше про­чи­тать пер­во­ис­точ­ник.

[codesyntax lang="php" blockstate="collapsed"]

[/codesyntax]

 

update_config

Настрой­ка обнов­ле­ния сервисов.

  • parallelism: Коли­че­ство одно­вре­мен­но обнов­ля­е­мых кон­тей­не­ров. Если уста­но­вить 0, то будет про­ис­хо­дить одно­вре­мен­ное обнов­ле­ние всех контейнеров.
  • delay: Задерж­ка меж­ду обнов­ле­ни­я­ми груп­пы кон­тей­не­ров (по умол­ча­нию: 0s).
  • failure_action: Дей­ствие при ошиб­ке обнов­ле­ния. Может при­ни­мать зна­че­ния: continuerollback, или pause (по умол­ча­нию: pause).
  • monitor: Про­дол­жи­тель­ность мони­то­рин­га на сбой после каж­до­го обнов­ле­ния (ns|us|ms|s|m|h)(по умол­ча­нию: 0s).
  • max_failure_ratio: Допу­сти­мая часто­та сбо­ев при обнов­ле­нии (по умол­ча­нию: 0).
  • order: Поря­док опе­ра­ций при обнов­ле­нии. Может при­ни­мать зна­че­ния: stop-first (ста­рая зада­ча оста­нав­ли­ва­ет­ся перед тем, как запус­кать новую), или start-first (сна­ча­ла запус­ка­ет­ся новая зада­ча, а выпол­ня­е­мые зада­чи нена­дол­го “пере­кры­ва­ют­ся”) (по умол­ча­нию: stop-first).

Замет­ка: Поря­док опе­ра­ций при обнов­ле­нии досту­пен начи­ная с вер­сии v3.4 и выше.

[codesyntax lang="php" blockstate="collapsed"]

[/codesyntax]

depends_on явля­ет­ся не будет рабо­тать при исполь­зо­ва­нии с docker stack deploy. Служ­бы режи­ма Swarm пере­за­пус­ка­ют­ся, когда они тер­пят неуда­чу, поэто­му нет при­чин откла­ды­вать их запуск. Даже если они тер­пят неуда­чу несколь­ко раз, они в конеч­ном ито­ге выздоровят(возможно)

rollback_config

Вер­сия 3.7 и выше

Настрой­ка отка­тов сер­ви­сов в слу­чае ошиб­ки обновления.

  • parallelism: Коли­че­ство одно­вре­мен­но отка­ты­ва­е­мых кон­тей­не­ров. Если уста­но­вить 0, то будет про­ис­хо­дить одно­вре­мен­ный откат всех контейнеров.
  • delay: Задерж­ка меж­ду отка­та­ми груп­пы кон­тей­не­ров (по умол­ча­нию: 0s).
  • failure_action: Дей­ствие при про­ва­ле отка­та. Может при­ни­мать зна­че­ния: continue или pause (по умол­ча­нию: pause)
  • monitor: Про­дол­жи­тель­ность мони­то­рин­га на сбой после каж­до­го обнов­ле­ния (ns|us|ms|s|m|h)(по умол­ча­нию: 0s).
  • max_failure_ratio: Допу­сти­мая часто­та сбо­ев при отка­те (по умол­ча­нию: 0).
  • order: Поря­док опе­ра­ций при отка­те. Может при­ни­мать зна­че­ния: stop-first (ста­рая зада­ча оста­нав­ли­ва­ет­ся перед тем, как запус­кать новую), или start-first (сна­ча­ла запус­ка­ет­ся новая зада­ча, а выпол­ня­е­мые зада­чи нена­дол­го “пере­кры­ва­ют­ся”) (по умол­ча­нию: stop-first).

Не поддерживается в контексте docker stack deploy

Сле­ду­ю­щие настрой­ки не под­дер­жи­ва­ют­ся коман­дой docker stack deploy или настрой­ка­ми в груп­пе deploy.

  • build
  • cgroup_parent
  • container_name
  • devices
  • tmpfs
  • external_links
  • links
  • network_mode
  • restart
  • security_opt
  • stop_signal
  • sysctls
  • userns_mode

Замет­ка: Смот­ри раз­дел как настра­и­вать тома для сер­ви­сов, swarm-ов и docker-stack.yml фай­лов. Исполь­зо­ва­ние томов под­дер­жи­ва­ет­ся, но они долж­ны быть скон­фи­гу­ри­ро­ва­ны как как име­но­ван­ные тома или свя­за­ны с сер­ви­са­ми, кото­рые в свою оче­редь предо­став­ля­ют доступ к необ­хо­ди­мым томам.

 

Отправка логов во fluent 

Допу­стим име­ет­ся сер­вис curator
[codesyntax lang="php" blockstate="collapsed"]

[/codesyntax]

опи­сы­ва­ем логи­ро­ва­ние сле­ду­ю­щим блоком:
logging:
driver: "fluentd"
options:
tag: CURATOR
driver гово­рит как назы­ва­ет­ся при­ни­ма­ю­щий логи драй­вер, tag - добав­ля­ет название.