Docker: image, networking ও Compose-এ Laravel

এই পাঠে যা শিখবেন

• Image build ও runtime config আলাদা রাখা
• Compose service name দিয়ে network বোঝা
• Laravel queue worker একই release থেকে চালানো

সমস্যা দিয়ে শুরু

Developer-এর laptop-এ checkout চলে, server-এ PHP extension অনুপস্থিত বলে fails। আরেক server পুরোনো Composer dependency চালায়। Docker-এর লক্ষ্য এই runtime পার্থক্য কমানো। শুধু Dockerfile লিখলেই production নিরাপদ হয় না: secret, writable directories, web server এবং database connection এখনও ঠিক করতে হয়। Deployment artifact যত reproducible হবে, ব্যর্থ release বুঝে ফেরত যাওয়া তত সহজ হবে।

সহজ করে বুঝি

Image build-এ PHP runtime, extensions, locked dependencies ও application code যোগ হয়। Runtime-এ environment থেকে configuration আসে। Compose local development-এ web, PHP, Redis ও database service-এর network ও volumes এক জায়গায় ঘোষণা করে। Container-এর localhost নিজের container; database service-এর নাম দিয়ে অন্য service-এ connect করতে হয়। Image tag চলমান নাম হতে পারে, digest নির্দিষ্ট artifact চিহ্নিত করে।

পরিচিত একটি উপমা

রান্নার নির্দিষ্ট recipe হলো image build। সেই recipe দিয়ে তৈরি প্রতিটি খাবার container instance। অতিথির পছন্দের মতো runtime configuration বদলাতে পারে; কিন্তু গোপন দরজার চাবি recipe বইয়ের মধ্যে ছাপানো ঠিক নয়।

নকশাটি দেখুন

flowchart LR
 B[Build locked source] --> I[Image registry]
 I --> W[Web container]
 I --> Q[Worker container]
 W --> R[Redis service]
 Q --> R
 W --> D[(Database volume)]

Build একবার হয়, registry থেকে web ও worker একই artifact নেয়। Redis service name তাদের internal network-এ resolve হয়। Database volume process lifecycle-এর বাইরে থাকে। HTTP server public/index.php-তে request পাঠায়; application root expose করে না। Worker-এর command আলাদা হলেও application version একই রাখলে payload compatibility বোঝা সহজ হয়।

PHP ও Laravel-এ প্রয়োগ

config/database.php-তে ব্যবহারের উপযোগী fragment। Standard Laravel mysql connection configuration-এর host অংশ দেখানো হয়েছে; বাকি credentials runtime environment-এ থাকবে। Local Compose-এ mysql service এবং pdo_mysql extension আছে ধরে নেওয়া হয়েছে। Production secret image-এ COPY করবেন না।

return [
    'default' => 'mysql',
    'connections' => [
        'mysql' => [
            'driver' => 'mysql',
            'host' => env('DB_HOST', 'mysql'),
            'database' => env('DB_DATABASE'),
            'username' => env('DB_USERNAME'),
            'password' => env('DB_PASSWORD'),
        ],
    ],
];

সুবিধা, সীমাবদ্ধতা ও trade-off

Reproducible image incident-এ version তুলনা সহজ করে। তবে large image pull ধীর হতে পারে, ভুল cached configuration অন্য environment-এর value বহন করতে পারে। Database container readiness ও app readiness এক নয়। Compose dependency start order চলমান database ready থাকার guarantee নয়; connection retry bounded হতে হবে। Development bind mount production release-এর সমতুল্য নয়।

সাধারণ ভুল

• DB_HOST=localhost দিয়ে অন্য container খোঁজা।
• Build layer-এ .env বা private Composer token রেখে দেওয়া।
• storage directory write permission না দিয়ে deploy করা।

আরও একটু গভীরে

Build context ছোট রাখুন, .dockerignore ব্যবহার করুন এবং non-root runtime বিবেচনা করুন। Application source read-only রাখলেও storage ও bootstrap/cache-এর প্রয়োজনীয় write path দিতে হবে। Config cache environment-sensitive: runtime secret পাওয়ার পরে সঠিক environment-এ cache তৈরি করুন। Web ও worker graceful stop করার সময় queue timeout এবং container termination grace মিলিয়ে নিন।

মনে রাখুন

Docker artifact স্থির করে; network, secrets, persistence ও lifecycle এখনও স্পষ্ট configuration চায়।

নিজে চেষ্টা করুন

Local Compose-এ DB_HOST বদলে localhost এবং service name-এর আচরণ তুলনা করুন। Redis restart করুন এবং request কীভাবে failure দেখায় লিখুন। তারপর image rebuild ছাড়া runtime config বদলানোর পরিকল্পনা তৈরি করুন।

নিজের বোঝা যাচাই করুন

1. Container-এর localhost কোথায়?

সেই container-এর network namespace-এ। অন্য database container ধরতে Compose service name বা সঠিক network address লাগে।

2. Image-এর মধ্যে .env রাখব?

না। Image registry ও build cache থেকে secret ছড়াতে পারে। Runtime secret injection ও সীমিত permissions ব্যবহার করুন।

3. Worker ও web একই image কেন?

একই source ও dependency artifact থেকে role অনুযায়ী command চালালে release mismatch কমে। তবু queued payload backward compatible রাখতে হবে।

4. depends_on কি recovery দেয়?

Startup ordering ও নির্দিষ্ট health condition দিতে পারে; দীর্ঘমেয়াদি dependency availability নিশ্চিত করে না। Application failure handling প্রয়োজন।

5. Volume থাকলেই backup?

না। Volume persistence দেয়, accidental delete বা corruption থেকে স্বতন্ত্র recovery point নয়। Backup এবং restore test আলাদা কাজ।

আরও পড়ুন

• Compose application model
• Laravel configuration