🥇Docker Compose. մշակումից մինչև արտադրություն

Դասընթացի մեկնարկին ընդառաջ պատրաստված փոդքասթի տառադարձության թարգմանությունը «Linux Administrator»

Docker Compose-ը աշխատանքի ստեղծման զարմանալի գործիք է
միջավայր ձեր հավելվածում օգտագործվող կույտի համար: Այն թույլ է տալիս սահմանել
Ձեր հավելվածի յուրաքանչյուր բաղադրիչ՝ հետևելով հստակ և պարզ շարահյուսությանը ՅԱՄԼ-
ֆայլեր.

-Ի գալուստով docker compose v3 այս YAML ֆայլերը կարող են օգտագործվել անմիջապես արտադրական միջավայրում, երբ աշխատում են դրա հետ
կլաստեր Docker ամբոխ.

Բայց արդյոք սա նշանակում է, որ դուք կարող եք օգտագործել նույն docker-compose ֆայլը
զարգացման գործընթացում և արտադրական միջավայրում. Կամ օգտագործեք նույն ֆայլը
բեմադրությո՞ւն։ Դե, ընդհանուր առմամբ, այո, բայց այս ֆունկցիոնալության համար մեզ անհրաժեշտ է հետևյալը.

Փոփոխական ինտերպոլացիա. որոշների համար շրջակա միջավայրի փոփոխականների օգտագործում
արժեքներ, որոնք փոխվում են յուրաքանչյուր միջավայրում:
Կազմաձևի անտեսում. երկրորդ (կամ որևէ մեկը) սահմանելու ունակություն
մեկ այլ հաջորդ) docker-compose ֆայլ, որը ինչ-որ բան կփոխի
նախ, և docker compose-ը կզբաղվի երկու ֆայլերի միաձուլմամբ:

Տարբերությունները զարգացման և արտադրության ֆայլերի միջև

Մշակման ընթացքում դուք, ամենայն հավանականությամբ, կցանկանաք ստուգել կոդի փոփոխությունները
իրական ժամանակ. Դա անելու համար սովորաբար տեղադրվում է սկզբնական կոդով ծավալը
կոնտեյներ, որը պարունակում է գործարկման ժամանակ ձեր հավելվածի համար: Բայց արտադրական միջավայրի համար
Այս մեթոդը հարմար չէ:

Արտադրության մեջ դուք ունեք բազմաթիվ հանգույցներով կլաստեր, և ծավալը տեղական է
համեմատ այն հանգույցի հետ, որի վրա աշխատում է ձեր կոնտեյները (կամ ծառայությունը), այնպես որ դուք դա չեք անում
դուք կարող եք տեղադրել աղբյուրի կոդը առանց բարդ գործողությունների, որոնք ներառում են
կոդի համաժամացում, ազդանշաններ և այլն:

Փոխարենը, մենք սովորաբար ցանկանում ենք պատկեր ստեղծել ձեր կոդի կոնկրետ տարբերակով:
Ընդունված է նշել այն համապատասխան պիտակով (կարող եք օգտագործել իմաստային
տարբերակում կամ ձեր հայեցողությամբ այլ համակարգ):

Կազմաձևման վերացում

Հաշվի առնելով տարբերությունները և այն, որ ձեր կախվածությունները կարող են տարբերվել սցենարներով
մշակում և արտադրություն, պարզ է, որ մեզ անհրաժեշտ կլինեն տարբեր կազմաձևման ֆայլեր:

Docker compose-ն աջակցում է տարբեր կազմման ֆայլերի միաձուլմանը
ստանալ վերջնական կոնֆիգուրացիան. Ինչպես է դա աշխատում, կարելի է տեսնել օրինակում.

$ cat docker-compose.yml
version: "3.2"

services:
  whale:
    image: docker/whalesay
    command: ["cowsay", "hello!"]
$ docker-compose up
Creating network "composeconfigs_default" with the default driver
Starting composeconfigs_whale_1
Attaching to composeconfigs_whale_1
whale_1  |  ________
whale_1  | < hello! >
whale_1  |  --------
whale_1  |     
whale_1  |      
whale_1  |       
whale_1  |                     ##        .
whale_1  |               ## ## ##       ==
whale_1  |            ## ## ## ##      ===
whale_1  |        /""""""""""""""""___/ ===
whale_1  |   ~~~ {~~ ~~~~ ~~~ ~~~~ ~~ ~ /  ===- ~~~
whale_1  |        ______ o          __/
whale_1  |                     __/
whale_1  |           __________/
composeconfigs_whale_1 exited with code 0

Ինչպես ասվեց, docker compose-ն աջակցում է բազմաթիվ կոմպոզիցիաների համադրմանը.
ֆայլեր, սա թույլ է տալիս վերացնել տարբեր պարամետրեր երկրորդ ֆայլում: Օրինակ:

$ cat docker-compose.second.yml
version: "3.2"
services:
  whale:
    command: ["cowsay", "bye!"]

$ docker-compose -f docker-compose.yml -f docker-compose.second.yml up
Creating composeconfigs_whale_1
Attaching to composeconfigs_whale_1
whale_1  |  ______
whale_1  | < bye! >
whale_1  |  ------
whale_1  |     
whale_1  |      
whale_1  |       
whale_1  |                     ##        .
whale_1  |               ## ## ##       ==
whale_1  |            ## ## ## ##      ===
whale_1  |        /""""""""""""""""___/ ===
whale_1  |   ~~~ {~~ ~~~~ ~~~ ~~~~ ~~ ~ /  ===- ~~~
whale_1  |        ______ o          __/
whale_1  |                     __/
whale_1  |           __________/
composeconfigs_whale_1 exited with code 0

Այս շարահյուսությունը մշակման ժամանակ այնքան էլ հարմար չէ, երբ հրամանը
անհրաժեշտ կլինի անել բազմիցս:

Բարեբախտաբար, docker compose-ը ավտոմատ կերպով փնտրում է հատուկ ֆայլ, որը կոչվում է
docker-compose.override.yml արժեքները վերացնելու համար դոկտոր-կոմպոզ.իմլ. Եթե
վերանվանեք երկրորդ ֆայլը, դուք կստանաք նույն արդյունքը, միայն օգտագործելով բնօրինակ հրամանը.

$ mv docker-compose.second.yml docker-compose.override.yml
$ docker-compose up
Starting composeconfigs_whale_1
Attaching to composeconfigs_whale_1
whale_1  |  ______
whale_1  | < bye! >
whale_1  |  ------
whale_1  |     
whale_1  |      
whale_1  |       
whale_1  |                     ##        .
whale_1  |               ## ## ##       ==
whale_1  |            ## ## ## ##      ===
whale_1  |        /""""""""""""""""___/ ===
whale_1  |   ~~~ {~~ ~~~~ ~~~ ~~~~ ~~ ~ /  ===- ~~~
whale_1  |        ______ o          __/
whale_1  |                     __/
whale_1  |           __________/
composeconfigs_whale_1 exited with code 0

Լավ, դա ավելի հեշտ է հիշելը:

Փոփոխականների ինտերպոլացիա

Կազմաձևման ֆայլերի աջակցություն ինտերպոլացիա
փոփոխականներ և լռելյայն արժեքներ: Այսինքն, դուք կարող եք անել հետևյալը.

services:
  my-service:
    build:
      context: .
    image: private.registry.mine/my-stack/my-service:${MY_SERVICE_VERSION:-latest}
...

Իսկ եթե անեք docker-compose build (կամ push) առանց շրջակա միջավայրի փոփոխականի
$MY_SERVICE_VERSION, արժեքը կօգտագործվի ամենավերջինբայց եթե սահմանես
շրջակա միջավայրի փոփոխականի արժեքը կառուցումից առաջ, այն կօգտագործվի կառուցելիս կամ մղելիս
գրանցամատյանին private.registry.mine.

Իմ սկզբունքները

Այն մոտեցումները, որոնք աշխատում են ինձ համար, կարող են աշխատել նաև ձեզ համար: Ես հետևում եմ սրանք
պարզ կանոններ.

Արտադրության, զարգացման (կամ այլ միջավայրերի) համար նախատեսված իմ բոլոր կույտերը սահմանվում են միջոցով
docker-compose ֆայլեր
Կազմաձևման ֆայլերը անհրաժեշտ են իմ բոլոր միջավայրերը հնարավորինս ծածկելու համար
խուսափել կրկնօրինակումից.
Ինձ պետք է մեկ պարզ հրաման՝ յուրաքանչյուր միջավայրում աշխատելու համար:
Հիմնական կոնֆիգուրացիան սահմանված է ֆայլում դոկտոր-կոմպոզ.իմլ.
Շրջակա միջավայրի փոփոխականները օգտագործվում են պատկերի պիտակները կամ այլ սահմանելու համար
փոփոխականներ, որոնք կարող են տարբեր լինել միջավայրից միջավայր (բեմականացում, ինտեգրում,
արտադրություն):
Արտադրության փոփոխականների արժեքները օգտագործվում են որպես արժեքներ
լռելյայնորեն, սա նվազագույնի է հասցնում ռիսկերը, եթե բուրգը արտադրվում է առանց
սահմանել միջավայրի փոփոխական:
Արտադրական միջավայրում ծառայություն սկսելու համար օգտագործեք հրամանը docker stack deploy - compose-file docker-compose.yml -with-registry-auth my-stack-name.
Աշխատանքային միջավայրը սկսվում է հրամանի միջոցով դոկտոր-կոմպոզիցիա-դ.

Եկեք նայենք մի պարզ օրինակի.

# docker-compose.yml
...
services:
  my-service:
    build:
      context: .
    image: private.registry.mine/my-stack/my-service:${MY_SERVICE_VERSION:-latest}
    environment:
      API_ENDPOINT: ${API_ENDPOINT:-https://production.my-api.com}
...

# docker-compose.override.yml
...
services:
  my-service:
    ports: # This is needed for development!
      - 80:80
    environment:
      API_ENDPOINT: https://devel.my-api.com
    volumes:
      - ./:/project/src
...

Ես կարող եմ օգտագործել docker-compose (docker-compose up)դարակը ներս գործարկելու համար
մշակման ռեժիմ՝ տեղադրված սկզբնաղբյուրով /նախագիծ/src.

Ես կարող եմ օգտագործել այս նույն ֆայլերը արտադրության մեջ: Եվ ես անպայման կարող էի օգտագործել
նույն ֆայլը դոկտոր-կոմպոզ.իմլ բեմադրության համար։ Սա ընդլայնելու համար
արտադրություն, ես պարզապես պետք է կառուցեմ և ուղարկեմ պատկերը նախապես սահմանված պիտակով
CI փուլում.

export MY_SERVICE_VERSION=1.2.3
docker-compose -f docker-compose.yml build
docker-compose -f docker-compose.yml push

Արտադրության մեջ սա կարող է գործարկվել՝ օգտագործելով հետևյալ հրամանները.

export MY_SERVICE_VERSION=1.2.3
docker stack deploy my-stack --compose-file docker-compose.yml --with-registry-auth

Իսկ եթե նույնն ես ուզում անել բեմում, ուղղակի պետք է սահմանել
Բեմական միջավայրում աշխատելու համար անհրաժեշտ միջավայրի փոփոխականներ.

export MY_SERVICE_VERSION=1.2.3
export API_ENDPOINT=http://staging.my-api.com
docker stack deploy my-stack --compose-file docker-compose.yml --with-registry-auth

Արդյունքում մենք օգտագործեցինք երկու տարբեր docker-compose ֆայլեր, որոնք առանց
Կրկնվող կոնֆիգուրացիաները կարող են օգտագործվել ձեր ցանկացած միջավայրի համար:

Իմացեք ավելին դասընթացի մասին «Linux Administrator»

Source: www.habr.com

Docker Compose. մշակումից մինչև արտադրություն

Տարբերությունները զարգացման և արտադրության ֆայլերի միջև

Կազմաձևման վերացում

Փոփոխականների ինտերպոլացիա

Իմ սկզբունքները

Добавить комментарий Չեղարկել պատասխանել