ಡಾಕರ್ ಸಂಯೋಜನೆ: ಅಭಿವೃದ್ಧಿಯಿಂದ ಉತ್ಪಾದನೆಗೆ

ಕೋರ್ಸ್‌ನ ಪ್ರಾರಂಭದ ನಿರೀಕ್ಷೆಯಲ್ಲಿ ಸಿದ್ಧಪಡಿಸಲಾದ ಪಾಡ್‌ಕ್ಯಾಸ್ಟ್ ಪ್ರತಿಲೇಖನದ ಅನುವಾದ "ಲಿನಕ್ಸ್ ನಿರ್ವಾಹಕರು"

ಡಾಕರ್ ಸಂಯೋಜನೆಯು ಕೆಲಸವನ್ನು ರಚಿಸಲು ಅದ್ಭುತ ಸಾಧನವಾಗಿದೆ
ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ ಬಳಸಲಾದ ಸ್ಟಾಕ್‌ಗೆ ಪರಿಸರ. ಇದು ವ್ಯಾಖ್ಯಾನಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ
ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನ ಪ್ರತಿಯೊಂದು ಘಟಕವು ಸ್ಪಷ್ಟ ಮತ್ತು ಸರಳ ಸಿಂಟ್ಯಾಕ್ಸ್ ಅನ್ನು ಅನುಸರಿಸುತ್ತದೆ YAML-
ಕಡತಗಳನ್ನು.

ಆಗಮನದೊಂದಿಗೆ ಡಾಕರ್ ಕಂಪೋಸ್ v3 ಕೆಲಸ ಮಾಡುವಾಗ ಈ YAML ಫೈಲ್‌ಗಳನ್ನು ನೇರವಾಗಿ ಉತ್ಪಾದನಾ ಪರಿಸರದಲ್ಲಿ ಬಳಸಬಹುದು
ಕ್ಲಸ್ಟರ್ ಡಾಕರ್ ಸ್ವಾರ್ಮ್.

ಆದರೆ ಇದರರ್ಥ ನೀವು ಅದೇ ಡಾಕರ್-ಕಂಪೋಸ್ ಫೈಲ್ ಅನ್ನು ಬಳಸಬಹುದು
ಅಭಿವೃದ್ಧಿ ಪ್ರಕ್ರಿಯೆ ಮತ್ತು ಉತ್ಪಾದನಾ ಪರಿಸರದಲ್ಲಿ? ಅಥವಾ ಅದೇ ಫೈಲ್ ಅನ್ನು ಬಳಸಿ
ವೇದಿಕೆಯ? ಸರಿ, ಸಾಮಾನ್ಯವಾಗಿ, ಹೌದು, ಆದರೆ ಈ ಕಾರ್ಯಕ್ಕಾಗಿ ನಮಗೆ ಈ ಕೆಳಗಿನವುಗಳು ಬೇಕಾಗುತ್ತವೆ:

• ವೇರಿಯಬಲ್ ಇಂಟರ್‌ಪೋಲೇಶನ್: ಕೆಲವರಿಗೆ ಪರಿಸರ ವೇರಿಯಬಲ್‌ಗಳನ್ನು ಬಳಸುವುದು
  ಪ್ರತಿ ಪರಿಸರದಲ್ಲಿ ಬದಲಾಗುವ ಮೌಲ್ಯಗಳು.
• ಕಾನ್ಫಿಗರೇಶನ್ ಅತಿಕ್ರಮಣ: ಸೆಕೆಂಡ್ ಅನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುವ ಸಾಮರ್ಥ್ಯ (ಅಥವಾ ಯಾವುದಾದರೂ
  ಮತ್ತೊಂದು ನಂತರದ) ಡಾಕರ್-ಕಂಪೋಸ್ ಫೈಲ್ ಅದು ಏನನ್ನಾದರೂ ಬದಲಾಯಿಸುತ್ತದೆ
  ಮೊದಲು, ಮತ್ತು ಡಾಕರ್ ಕಂಪೋಸ್ ಎರಡೂ ಫೈಲ್‌ಗಳನ್ನು ವಿಲೀನಗೊಳಿಸುವುದನ್ನು ನೋಡಿಕೊಳ್ಳುತ್ತದೆ.

ಅಭಿವೃದ್ಧಿ ಮತ್ತು ಉತ್ಪಾದನಾ ಫೈಲ್‌ಗಳ ನಡುವಿನ ವ್ಯತ್ಯಾಸಗಳು

ಅಭಿವೃದ್ಧಿಯ ಸಮಯದಲ್ಲಿ, ನೀವು ಹೆಚ್ಚಾಗಿ ಕೋಡ್ ಬದಲಾವಣೆಗಳನ್ನು ಪರಿಶೀಲಿಸಲು ಬಯಸುತ್ತೀರಿ
ನೈಜ ಸಮಯ. ಇದನ್ನು ಮಾಡಲು, ಸಾಮಾನ್ಯವಾಗಿ ಮೂಲ ಕೋಡ್‌ನೊಂದಿಗೆ ವಾಲ್ಯೂಮ್ ಅನ್ನು ಜೋಡಿಸಲಾಗುತ್ತದೆ
ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗಾಗಿ ರನ್‌ಟೈಮ್ ಹೊಂದಿರುವ ಕಂಟೇನರ್. ಆದರೆ ಉತ್ಪಾದನಾ ವಾತಾವರಣಕ್ಕಾಗಿ
ಈ ವಿಧಾನವು ಸೂಕ್ತವಲ್ಲ.

ಉತ್ಪಾದನೆಯಲ್ಲಿ, ನೀವು ಅನೇಕ ನೋಡ್ಗಳೊಂದಿಗೆ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಹೊಂದಿದ್ದೀರಿ, ಮತ್ತು ಪರಿಮಾಣವು ಸ್ಥಳೀಯವಾಗಿದೆ
ನಿಮ್ಮ ಕಂಟೇನರ್ (ಅಥವಾ ಸೇವೆ) ಚಾಲನೆಯಲ್ಲಿರುವ ನೋಡ್‌ಗೆ ಸಂಬಂಧಿಸಿದಂತೆ, ಆದ್ದರಿಂದ ನೀವು ಹಾಗೆ ಮಾಡುವುದಿಲ್ಲ
ಒಳಗೊಂಡಿರುವ ಸಂಕೀರ್ಣ ಕಾರ್ಯಾಚರಣೆಗಳಿಲ್ಲದೆ ನೀವು ಮೂಲ ಕೋಡ್ ಅನ್ನು ಆರೋಹಿಸಬಹುದು
ಕೋಡ್ ಸಿಂಕ್ರೊನೈಸೇಶನ್, ಸಂಕೇತಗಳು, ಇತ್ಯಾದಿ.

ಬದಲಿಗೆ, ನಾವು ಸಾಮಾನ್ಯವಾಗಿ ನಿಮ್ಮ ಕೋಡ್‌ನ ನಿರ್ದಿಷ್ಟ ಆವೃತ್ತಿಯೊಂದಿಗೆ ಚಿತ್ರವನ್ನು ರಚಿಸಲು ಬಯಸುತ್ತೇವೆ.
ಅದನ್ನು ಸೂಕ್ತವಾದ ಟ್ಯಾಗ್‌ನೊಂದಿಗೆ ಗುರುತಿಸುವುದು ವಾಡಿಕೆ (ನೀವು ಶಬ್ದಾರ್ಥವನ್ನು ಬಳಸಬಹುದು
ಆವೃತ್ತಿ ಅಥವಾ ನಿಮ್ಮ ವಿವೇಚನೆಯಿಂದ ಇನ್ನೊಂದು ವ್ಯವಸ್ಥೆ).

ಕಾನ್ಫಿಗರೇಶನ್ ಅತಿಕ್ರಮಣ

ವ್ಯತ್ಯಾಸಗಳನ್ನು ನೀಡಲಾಗಿದೆ ಮತ್ತು ನಿಮ್ಮ ಅವಲಂಬನೆಗಳು ಸನ್ನಿವೇಶಗಳಲ್ಲಿ ಭಿನ್ನವಾಗಿರಬಹುದು
ಅಭಿವೃದ್ಧಿ ಮತ್ತು ಉತ್ಪಾದನೆ, ನಮಗೆ ವಿಭಿನ್ನ ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್‌ಗಳು ಬೇಕಾಗುತ್ತವೆ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ.

ಡಾಕರ್ ಕಂಪೋಸ್ ವಿವಿಧ ಕಂಪೋಸ್ ಫೈಲ್‌ಗಳನ್ನು ವಿಲೀನಗೊಳಿಸುವುದನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ
ಅಂತಿಮ ಸಂರಚನೆಯನ್ನು ಪಡೆಯಿರಿ. ಇದು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಉದಾಹರಣೆಯಲ್ಲಿ ಕಾಣಬಹುದು:

$ 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

ಈ ಸಿಂಟ್ಯಾಕ್ಸ್ ಅಭಿವೃದ್ಧಿಯ ಸಮಯದಲ್ಲಿ ತುಂಬಾ ಅನುಕೂಲಕರವಾಗಿಲ್ಲ, ಯಾವಾಗ ಆಜ್ಞೆ
ಹಲವು ಬಾರಿ ಮಾಡಬೇಕಾಗುತ್ತದೆ.

ಅದೃಷ್ಟವಶಾತ್, ಡಾಕರ್ ಕಂಪೋಸ್ ಎಂಬ ವಿಶೇಷ ಫೈಲ್ ಅನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಹುಡುಕುತ್ತದೆ
ಡಾಕರ್-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

ಸರಿ, ಅದನ್ನು ನೆನಪಿಟ್ಟುಕೊಳ್ಳುವುದು ಸುಲಭ.

ವೇರಿಯೇಬಲ್ಸ್ ಇಂಟರ್ಪೋಲೇಷನ್

ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್‌ಗಳ ಬೆಂಬಲ ಪ್ರಕ್ಷೇಪಣ
ಅಸ್ಥಿರ ಮತ್ತು ಡೀಫಾಲ್ಟ್ ಮೌಲ್ಯಗಳು. ಅಂದರೆ, ನೀವು ಈ ಕೆಳಗಿನವುಗಳನ್ನು ಮಾಡಬಹುದು:

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.yml.
• ಚಿತ್ರದ ಟ್ಯಾಗ್‌ಗಳು ಅಥವಾ ಇತರವನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಲು ಪರಿಸರ ಅಸ್ಥಿರಗಳನ್ನು ಬಳಸಲಾಗುತ್ತದೆ
  ಪರಿಸರದಿಂದ ಪರಿಸರಕ್ಕೆ ಬದಲಾಗಬಹುದಾದ ಅಸ್ಥಿರಗಳು (ವೇದಿಕೆ, ಏಕೀಕರಣ,
  ಉತ್ಪಾದನೆ).
• ಉತ್ಪಾದನಾ ಅಸ್ಥಿರಗಳ ಮೌಲ್ಯಗಳನ್ನು ಮೌಲ್ಯಗಳಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ
  ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ, ಸ್ಟಾಕ್ ಅನ್ನು ಇಲ್ಲದೆ ಉತ್ಪಾದನೆಯಲ್ಲಿ ಪ್ರಾರಂಭಿಸಿದರೆ ಇದು ಅಪಾಯಗಳನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ
  ಪರಿಸರ ವೇರಿಯಬಲ್ ಅನ್ನು ಹೊಂದಿಸಿ.
• ಉತ್ಪಾದನಾ ಪರಿಸರದಲ್ಲಿ ಸೇವೆಯನ್ನು ಪ್ರಾರಂಭಿಸಲು, ಆಜ್ಞೆಯನ್ನು ಬಳಸಿ ಡಾಕರ್ ಸ್ಟಾಕ್ ನಿಯೋಜನೆ - ಕಂಪೋಸ್-ಫೈಲ್ ಡಾಕರ್-ಕಂಪೋಸ್.ಎಂಎಲ್ -ವಿತ್-ರಿಜಿಸ್ಟ್ರಿ-ಆತ್ my-ಸ್ಟಾಕ್-ಹೆಸರು.
• ಆಜ್ಞೆಯನ್ನು ಬಳಸಿಕೊಂಡು ಕೆಲಸದ ವಾತಾವರಣವನ್ನು ಪ್ರಾರಂಭಿಸಲಾಗಿದೆ ಡಾಕರ್-ಕಂಪೋಸ್ ಅಪ್-ಡಿ.

ಒಂದು ಸರಳ ಉದಾಹರಣೆಯನ್ನು ನೋಡೋಣ.

# 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.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

ಪರಿಣಾಮವಾಗಿ, ನಾವು ಎರಡು ವಿಭಿನ್ನ ಡಾಕರ್-ಕಂಪೋಸ್ ಫೈಲ್‌ಗಳನ್ನು ಬಳಸಿದ್ದೇವೆ, ಅದು ಇಲ್ಲದೆ
ನೀವು ಹೊಂದಿರುವ ಯಾವುದೇ ಪರಿಸರಕ್ಕೆ ನಕಲಿ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳನ್ನು ಬಳಸಬಹುದು!

ಕೋರ್ಸ್ ಬಗ್ಗೆ ಇನ್ನಷ್ಟು ತಿಳಿಯಿರಿ "ಲಿನಕ್ಸ್ ನಿರ್ವಾಹಕರು"

ಮೂಲ: www.habr.com