🥇 ڊڪر ڪمپوز: ترقي کان پيداوار تائين

ڪورس جي شروعات جي توقع ۾ تيار ڪيل پوڊ ڪاسٽ ٽرانسپشن جو ترجمو "لينڪس ايڊمنسٽريٽر"

ڊاڪر ڪمپوز ڪم ڪرڻ لاءِ هڪ شاندار اوزار آهي
توهان جي ايپليڪيشن ۾ استعمال ٿيل اسٽيڪ لاء ماحول. اهو توهان کي وضاحت ڪرڻ جي اجازت ڏئي ٿو
توهان جي ايپليڪيشن جو هر حصو، هڪ صاف ۽ سادي نحو جي پٺيان YAML-
فائلون.

جي آمد سان ڊڪر ڪمپوز v3 اهي YAML فائلون سڌو سنئون پيداوار جي ماحول ۾ استعمال ڪري سگھجن ٿيون جڏهن ڪم ڪرڻ سان
ڪلستر دکائيندڙ تلوار.

پر ڇا هن جو مطلب اهو آهي ته توهان ساڳئي ڊاکر-compose فائل ۾ استعمال ڪري سگهو ٿا
ترقي جي عمل ۽ پيداوار جي ماحول ۾؟ يا ساڳئي فائل لاء استعمال ڪريو
اسٽيجنگ؟ خير، عام طور تي، ها، پر هن ڪارڪردگي لاء اسان کي هيٺين جي ضرورت آهي:

Variable interpolation: ڪجھ لاءِ ماحوليات جي متغير استعمال ڪندي
قدر جيڪي هر ماحول ۾ تبديل ٿيندا آهن.
ڪنفيگريشن اوور رائڊ: هڪ سيڪنڊ جي وضاحت ڪرڻ جي صلاحيت (يا ڪو
ٻيو ايندڙ) ڊاڪر-ڪپوز فائل جيڪو ڪجهه تبديل ڪندو
پهريون، ۽ ڊاکر ڪمپوز ٻنهي فائلن کي ضم ڪرڻ جو خيال رکندو.

ترقي ۽ پيداوار فائلن جي وچ ۾ فرق

ترقي جي دوران، توهان گهڻو ڪري چاھيو ٿا ڪوڊ تبديلين ۾ چيڪ ڪريو
حقيقي وقت. هن کي ڪرڻ لاء، عام طور تي ماخذ ڪوڊ سان حجم نصب ٿيل آهي
ڪنٽينر جيڪو توهان جي ايپليڪيشن لاءِ رن ٽائم تي مشتمل آهي. پر پيداوار جي ماحول لاء
اهو طريقو مناسب ناهي.

پيداوار ۾، توهان وٽ ڪيترن ئي نوڊس سان ڪلستر آهي، ۽ حجم مقامي آهي
نوڊ جي نسبت سان جنهن تي توهان جو ڪنٽينر (يا خدمت) هلندڙ آهي، تنهنڪري توهان نٿا ڪريو
توھان بغير پيچيدگين عملن جي سورس ڪوڊ کي نصب ڪري سگھو ٿا جيڪي شامل آھن
ڪوڊ هم وقت سازي، سگنل، وغيره.

ان جي بدران، اسان عام طور تي توهان جي ڪوڊ جي مخصوص ورزن سان هڪ تصوير ٺاهڻ چاهيون ٿا.
اهو رواج آهي ته ان کي مناسب ٽيگ سان نشان لڳايو (توهان استعمال ڪري سگهو ٿا semantic
نسخي يا ٻيو سسٽم توهان جي صوابديد تي).

ڪنفيگريشن اوور رائڊ

اختلافن کي ڏنو ويو آهي ۽ توهان جا انحصار شايد منظرنامي ۾ مختلف ٿي سگهن ٿا
ترقي ۽ پيداوار، اهو واضح آهي ته اسان کي مختلف ترتيبن جي فائلن جي ضرورت پوندي.

ڊاکر ڪمپوز مختلف ڪمپوز فائلن کي ضم ڪرڻ جي سپورٽ ڪري ٿو
آخري ترتيب حاصل ڪريو. اهو ڪيئن ڪم ڪري ٿو مثال ۾ ڏسي سگهجي ٿو:

$ 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

جيئن چيو ويو آهي، ڊاکر ڪمپوز ڪيترن ئي مرکبن کي گڏ ڪرڻ جي حمايت ڪري ٿو -
فائلون، هي توهان کي ٻئي فائل ۾ مختلف پيٽرولن کي ختم ڪرڻ جي اجازت ڏئي ٿو. مثال طور:

$ 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.override.yml قدرن کي ختم ڪرڻ docker-compose.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

ٺيڪ آهي، اهو ياد رکڻ آسان آهي.

متغيرن جو Interpolation

ڪنفيگريشن فائلن جي سپورٽ مداخلت
متغير ۽ ڊفالٽ قدر. اهو آهي، توهان هيٺيان ڪري سگهو ٿا:

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

۽ جيڪڏھن اوھين ڪندا ڊاکر ٺاھڻ (يا ڌڪ) ماحولياتي تبديليءَ کان سواءِ
$MY_SERVICE_VERSION، قدر استعمال ڪيو ويندو جديدپر جيڪڏهن توهان مقرر ڪيو
تعمير کان اڳ ماحول جي متغير جو قدر، اهو استعمال ڪيو ويندو جڏهن تعمير ڪرڻ يا زور ڏيڻ
رجسٽر ڏانهن private.registry.mine.

منهنجا اصول

اهي طريقا جيڪي مون لاءِ ڪم ڪن ٿا شايد توهان لاءِ پڻ ڪم ڪن. مان انهن جي پيروي ڪريان ٿو
سادي اصول:

پيداوار، ترقي (يا ٻيون ماحول) لاءِ منهنجا سڀئي اسٽيڪ جي ذريعي وضاحت ڪئي وئي آهي
docker-compose فائلون
منهنجي سڀني ماحول کي ڍڪڻ لاءِ ترتيب واري فائلن جي ضرورت آهي، جيترو ٿي سگهي
نقل ڪرڻ کان پاسو ڪريو.
مون کي هر ماحول ۾ ڪم ڪرڻ لاءِ هڪ سادي حڪم جي ضرورت آهي.
مکيه تشڪيل فائل ۾ بيان ڪيو ويو آهي docker-compose.yml.
تصويري ٽيگ يا ٻيون وضاحتون ڪرڻ لاءِ ماحولياتي متغير استعمال ٿيندا آهن
متغير جيڪي مختلف ٿي سگهن ٿا ماحول کان ماحول تائين (اسٽيجنگ، انضمام،
پيداوار).
پيداوار جي متغيرن جي قدرن لاءِ قدرن جي طور تي استعمال ٿيل آھن
ڊفالٽ طور، هي خطرن کي گھٽائي ٿو جيڪڏهن اسٽيڪ بغير پيداوار ۾ شروع ڪيو وڃي
ماحولياتي متغير مقرر ڪريو.
پيداوار واري ماحول ۾ خدمت شروع ڪرڻ لاءِ، ڪمانڊ استعمال ڪريو 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)اسٽيڪ کي هلائڻ لاءِ
ڊولپمينٽ موڊ ۾ سورس ڪوڊ نصب ٿيل آهي /project/src.

مان پيداوار ۾ اهي ساڳيون فائلون استعمال ڪري سگهان ٿو! ۽ مان ضرور استعمال ڪري سگهان ٿو
ساڳي فائل docker-compose.yml اسٽيج ڪرڻ لاء. انهي کي وڌائڻ لاء
پيداوار، مون کي صرف تصوير ٺاهڻ ۽ موڪلڻ جي ضرورت آهي اڳواٽ بيان ڪيل ٽيگ سان
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

نتيجي طور، اسان استعمال ڪيو ٻه مختلف ڊاکر-compose فائلون، جيڪي بغير
توهان وٽ موجود ڪنهن به ماحول لاءِ نقل ٺاهي سگھجن ٿا!

ڪورس بابت وڌيڪ ڄاڻو "لينڪس ايڊمنسٽريٽر"

جو ذريعو: www.habr.com

Docker Compose: ترقي کان پيداوار تائين

ترقي ۽ پيداوار فائلن جي وچ ۾ فرق

ڪنفيگريشن اوور رائڊ

متغيرن جو Interpolation

منهنجا اصول

تبصرو شامل ڪريو جواب منسوخ