ಆಧುನಿಕ ಫ್ರಂಟ್ ಎಂಡ್ ಇಂಜಿನಿಯರಿಂಗ್ ಒಂದು ದಶಕದ ಹಿಂದೆ ಇದ್ದ ಹಾಗೆ ಇಲ್ಲ. ನೀವು ಕೇವಲ HTML ಮತ್ತು CSS ಬರೆಯುತ್ತಿಲ್ಲ. ಈಗಿನ ಒಂದು ಸಾಮಾನ್ಯ ಪ್ರಾಜೆಕ್ಟ್ ಒಂದು ನಿರ್ದಿಷ್ಟ Node.js runtime, ಲಾಕ್ ಮಾಡಲಾದ package manager ವರ್ಷನ್, ಬಿಲ್ಡ್ ಟೂಲ್‌ಗಳ ಜಟಿಲತೆ ಮತ್ತು ಎಲ್ಲವೂ ಸರಿಯಾಗಿ ಹೊಂದಿಕೆಯಾಗಬೇಕೆಂದು ನಿರೀಕ್ಷಿಸುವ deployment pipelines ಗಳೊಂದಿಗೆ ಬರುತ್ತದೆ. ಮೊದಲ npm install ಮತ್ತು ಅಂತಿಮ production build ನಡುವೆ, ಸಣ್ಣ ವ್ಯತ್ಯಾಸಗಳು ಉಂಟಾಗುತ್ತವೆ. ನಿಮ್ಮ ಸಹೋದ್ಯೋಗಿ Node 20 ಬಳಸುತ್ತಿದ್ದಾರೆ, ನೀವು Node 18 ಬಳಸುತ್ತಿದ್ದೀರಿ. ನಿಮ್ಮ ಮೆಷಿನಿನಲ್ಲಿರುವ ಒಂದು global CLI tool ಅವರ ಮೆಷಿನಿನಲ್ಲಿ ಮಿಸ್ ಆಗಿರುವ dependency ಅನ್ನು ಮರೆಮಾಚಬಹುದು. ನಂತರ ಯಾರೂ ಕೇಳಲು ಬಯಸದ ಆ ವಾಕ್ಯ ಬರುತ್ತದೆ: "ಇದು ನನ್ನ ಮೆಷಿನಿನಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ" (It works on my machine).

Docker ನಿಮ್ಮ ಫ್ರಂಟ್ ಎಂಡ್ ಟೂಲ್‌ಕಿಟ್‌ನಲ್ಲಿ ತನ್ನದೇ ಆದ ಸ್ಥಾನವನ್ನು ಪಡೆದುಕೊಂಡಿದೆ, ಏಕೆಂದರೆ ಅದು ಆ ಅನಿಶ್ಚಿತತೆಯನ್ನು ಹೋಗಲಾಡಿಸುತ್ತದೆ. ಇದು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಅದಕ್ಕೆ ಬೇಕಾದ ನಿಖರವಾದ runtime, system libraries ಮತ್ತು dependencies ಗಳೊಂದಿಗೆ ಒಟ್ಟುಗೂಡಿಸುತ್ತದೆ. ನೀವು Windows ನಲ್ಲಿ ಕೋಡಿಂಗ್ ಮಾಡುತ್ತಿರಲಿ, macOS ನಿಂದ ಶಿಪ್ ಮಾಡುತ್ತಿರಲಿ ಅಥವಾ Linux cloud instance ಗೆ ಡಿಪ್ಲಾಯ್ ಮಾಡುತ್ತಿರಲಿ, ಅದರ ವರ್ತನೆಯು ಒಂದೇ ರೀತಿಯಾಗಿರುತ್ತದೆ.

ಫ್ರಂಟ್ ಎಂಡ್ ಡೆವಲಪರ್‌ಗಳು ಏಕೆ ಕಾಳಜಿ ವಹಿಸಬೇಕು

Docker ಪರಿಹರಿಸುವ ಸಮಸ್ಯೆಗಳು ಕೇವಲ ಕಾಲ್ಪನಿಕವಲ್ಲ. ಅವು ಪ್ರತಿ ಸ್ಪ್ರಿಂಟ್‌ನಲ್ಲಿಯೂ ಎದುರಾಗುತ್ತವೆ.

Version conflicts ಸಮಯವನ್ನು ವ್ಯರ್ಥ ಮಾಡುತ್ತವೆ. ಒಂದು legacy client project ಗೆ Node 18 ಬೇಕಾಗಬಹುದು, ನಿಮ್ಮ side project ಗೆ Node 20 ಬೇಕಾಗಬಹುದು ಮತ್ತು ಹೊಸ startup ಕೆಲಸಕ್ಕೆ Node 22 ಬೇಕಾಗಬಹುದು. Containers ಇಲ್ಲದೆ, ನೀವು ಇದನ್ನು version managers ಮೂಲಕ ನಿರ್ವಹಿಸುತ್ತೀರಿ. ಅದು ಕೆಲಸ ಮಾಡುವವರೆಗೆ ಮಾತ್ರ ಸರಿ. ಒಂದು ಸಣ್ಣ npm version mismatch peer dependencies ಹೇಗೆ ಪರಿಹರಿಸಲ್ಪಡುತ್ತದೆ ಎಂಬುದನ್ನು ಬದಲಾಯಿಸಬಹುದು, ಇದು ಬೇರೆಯವರಿಗೆ ಸರಿಯಾಗಿ ಕೆಲಸ ಮಾಡುವ build ಅನ್ನು ನಿಮಗೆ ಬ್ರೋಕನ್ ಆಗಿ ಬಿಡಬಹುದು. ಒಂದು framework ಹೊಸ release ಅನ್ನು ಘೋಷಿಸಿದಾಗ, ಫೀಡ್‌ಬ್ಯಾಕ್ ಲೂಪ್ ಎಂದರೆ ಎರಡು ಗಂಟೆಗಳ reinstall ಆಗಿರಬಾರದು. ಅದು ಕೇವಲ ಒಂದು ಫೈಲ್ ಬದಲಾವಣೆ ಮತ್ತು container restart ಆಗಿರಬೇಕು.

Global packages ಎಂಬುದು ಮೌನ ಅಡಚಣೆಗಳ ಮತ್ತೊಂದು ಮೂಲವಾಗಿದೆ. ನೀವು ಆರು ತಿಂಗಳ ಹಿಂದೆಯೇ ಇನ್‌ಸ್ಟಾಲ್ ಮಾಡಿದ Angular CLI, Expo ಅಥವಾ Prisma ಅನ್ನು global ಆಗಿ ಹೊಂದಿರಬಹುದು. ಹೊಸ ಡೆವಲಪರ್ ಅದೇ ಟೂಲ್ ಅನ್ನು ಹೊಸದಾಗಿ ಇನ್‌ಸ್ಟಾಲ್ ಮಾಡಿದಾಗ ಅವರಿಗೆ ಬೇರೆ ವರ್ಷನ್ ಸಿಗಬಹುದು. ಇದ್ದಕ್ಕಿದ್ದಂತೆ ನಿಮ್ಮ build scripts ಎಲ್ಲಿಯೂ ಕಾಣಿಸದ ಎಚ್ಚರಿಕೆಗಳನ್ನು (warnings) ನೀಡಬಹುದು. Docker ಎಲ್ಲವನ್ನೂ project-local ಆಗಿ ಇಡುವ ಮೂಲಕ ಇದನ್ನು ಸರಿಪಡಿಸುತ್ತದೆ. ನೀವು Dockerfile ನಲ್ಲಿ Node version ಅನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತೀರಿ. Dependencies ನಿಮ್ಮ host Operating System ನಿಂದ ಪ್ರತ್ಯೇಕವಾಗಿ, container ಒಳಗೆ ಇನ್‌ಸ್ಟಾಲ್ ಆಗುತ್ತವೆ. ನಿಮ್ಮ ಲ್ಯಾಪ್‌ಟಾಪ್ macOS, Windows ಅಥವಾ Ubuntu ಆಗಿರಬಹುದು; ಅಪ್ಲಿಕೇಶನ್ ಪ್ರತಿ ಬಾರಿಯೂ ನಿಖರವಾದ ಒಂದೇ ರೀತಿಯ ಎನ್ವಿರಾನ್ಮೆಂಟ್ ಅನ್ನು ನೋಡುತ್ತದೆ.

Onboarding ಪ್ರಯೋಜನಗಳನ್ನು ನಿರ್ಲಕ್ಷಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಹೊಸ ಉದ್ಯೋಗಿಗಳಿಗೆ Homebrew ಇನ್‌ಸ್ಟಾಲ್‌ಗಳು, nvm aliases ಮತ್ತು global permission fixes ಒಳಗೊಂಡ ಮೂರು ಪುಟಗಳ readme ಅಗತ್ಯವಿಲ್ಲ. ಅವರು Docker ಅನ್ನು ಇನ್‌ಸ್ಟಾಲ್ ಮಾಡುತ್ತಾರೆ, repository ಅನ್ನು ಕ್ಲೋನ್ ಮಾಡುತ್ತಾರೆ ಮತ್ತು ಒಂದು ಕಮಾಂಡ್ ರನ್ ಮಾಡುತ್ತಾರೆ. ಒಂದು ಕಾಲದಲ್ಲಿ ಒಂದು ಮಧ್ಯಾಹ್ನ ತೆಗೆದುಕೊಳ್ಳುತ್ತಿದ್ದ setup ಈಗ ನಿಮಿಷಗಳಲ್ಲಿ ಮುಗಿಯುತ್ತದೆ. ಮತ್ತು ಅವರು ಪ್ರಾಜೆಕ್ಟ್‌ಗಳನ್ನು ಬದಲಾಯಿಸಿದಾಗ, ಯಾವುದೂ ಉಳಿದುಬಿಡುವುದಿಲ್ಲ. ಯಾವುದೇ ಅನಾಥ global tools ಇರುವುದಿಲ್ಲ. PATH ಪ್ರೆಸಿಡೆನ್ಸ್ (precedence) ಗಾಗಿ ಹೋರಾಡುವ version managers ಇರುವುದಿಲ್ಲ. ಅವರ ಲೋಕಲ್ ಮೆಷಿನ್ ಸ್ವಚ್ಛವಾಗಿರುತ್ತದೆ.

ಇಮೇಜ್‌ಗಳು ಮತ್ತು ಕಂಟೇನರ್‌ಗಳು: ಮೂಲಭೂತ ಅಂಶಗಳು

Docker ನಿಮಗೆ ಹೊಸದಾಗಿದ್ದರೆ, ಇದರ ಪಾರಿಭಾಷಿಕ ಪದಗಳು ಕೇಳುವതിಗಿಂತ ಸರಳವಾಗಿವೆ. Docker image ಎಂಬುದು ಒಂದು ನೀಲನಕ್ಷೆ (blueprint). ಇದು ನಿಮ್ಮ source code, Node.js runtime, ನಿಮ್ಮ lockfile ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಚಲಾಯಿಸಲು ಅಗತ್ಯವಿರುವ ಪ್ರತಿಯೊಂದು dependency ಅನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ. Container ಎಂಬುದು ಆ image ನಿಂದ ರಚಿಸಲಾದ ಒಂದು live instance ಆಗಿದೆ. Image ಅನ್ನು ಅಡುಗೆ ವಿಧಾನ (recipe) ಎಂದು ಮತ್ತು container ಅನ್ನು ನಿಜವಾದ ಅಡುಗೆ (meal) ಎಂದು ಭಾವಿಸಿ. ನೀವು ಒಂದೇ ಅಡುಗೆ ವಿಧಾನದಿಂದ ನೂರು ಬಾರಿ ಒಂದೇ ಕೇಕ್ ಅನ್ನು ತಯಾರಿಸಬಹುದು. ನಿಮ್ಮ host computer ನಲ್ಲಿ ಏನೆಲ್ಲಾ ಇನ್‌ಸ್ಟಾಲ್ ಆಗಿದೆ ಎಂಬುದರ ಬಗ್ಗೆ ಚಿಂತಿಸದೆ, ಒಂದೇ image ನಿಂದ ಒಂದೇ ರೀತಿಯ containers ಗಳನ್ನು ನೀವು ರಚಿಸಬಹುದು.

ಒಂದು ಪ್ರಾಯೋಗಿಕ Dockerfile

ನಾವು ಒಂದು ನಿರ್ದಿಷ್ಟ ಆರಂಭಿಕ ಹಂತವನ್ನು ನೋಡೋಣ. ನೀವು