انتخاب روش مناسب برای بالا آوردن چند سایت با داکر(prod/dev)

network
docker

#1

سلام

من برای ران کردن کانتینرهای یک یا چند سایت به این صورت عمل کردم

‍‍‍فایل های زیر برای docker-compose درست شدن:

nginx.yml : توی این فایل فقط کانتینر nginx هست

version: "2"

services:     
  nginx:
    image: mojtabanaserei/nginx:1.15.5
    container_name: nginx
    ports:
      - "9000:9000"
    restart: always
     

site1.yml : توی این فایل تنظیمات سایت اول

version: "2"

services:
  site_test:
    image: mojtabanaserei/nginx:1.15.5
    container_name: site_test
    ports:
      - "2000:2000"
    restart: always
   

network.yml : توی این فایل شبکه هایی که برای هر کانتینر لازم هست

‍
version: "2"

services:     
  nginx:
    networks:
      nginx_to_site_test:
        ipv4_address: 172.20.1.2 
       
  site_test:
    networks:
      nginx_to_site_test:
        ipv4_address: 172.20.1.3 

networks:
  nginx_to_site_test:
    driver: bridge
    ipam:
      driver: default
      config:
       - subnet: 172.20.1.0/24

بعد با دستور زیر ران کنم


sudo docker-compose -f nginx.yml -f site1.yml  -f network.yml up -d 

اگر یک سایت دیگه بخوام اضافه بکنم شکل بالا به صورت زیر میشه

یک فایل اضافه میشه به اسم site2.yml

version: "2"

services:
  site_bbbb:
    image: mojtabanaserei/nginx:1.15.5
    container_name: site_bbbb
    ports:
      - "7000:7000"
    restart: always

و فایل network.yml هم به این صورت تغییر میکنه

version: "2"

services:     
  nginx:
    networks:
      nginx_to_site_test:
        ipv4_address: 172.20.1.2 
      nginx_to_site_bbbb:
        ipv4_address: 172.20.2.2 
       
  site_test:
    networks:
      nginx_to_site_test:
        ipv4_address: 172.20.1.3 
  site_bbbb:
    networks:
      nginx_to_site_bbbb:
        ipv4_address: 172.20.2.3 
        
 
networks:
  nginx_to_site_test:
    driver: bridge
    ipam:
      driver: default
      config:
       - subnet: 172.20.1.0/24
  nginx_to_site_bbbb:
    driver: bridge
    ipam:
      driver: default
      config:
       - subnet: 172.20.2.0/24
       
  

و در نهایت برای ران کردنشون به این صورت عمل میکنم

sudo docker-compose -f nginx.yml -f site1.yml -f site2.yml -f network.yml up -d 

ولی اگر خواستم کانتینرهای یک سایت رو دان کنم مثلا برای site1 میتونم این دستور رو بزنم

‍sudo docker-compose  -f site1.yml down

ولی نباید به این صورت ران بشه

‍sudo docker-compose -f site2.yml

چون باعث میشه تا یک شبکه پیشفرض درست بکنه و اون کانتینر رو در اون شبکه قرار بده

البته هدف از تنظیمات بالا فقط شبکه بندی کانتینرها هست در غیر این صورت باید فایل nginx.yml هم بروزرسانی میشد و برای هر سایت از image های دیگه استفاده میشد . مزیت روش بالا اینه که میشه راحت تر کانتینرها رو مدیریت کرد

اگر راه بهتری وجود داره دوستان لطفا نظرشون رو در مورد روش بالا عنوان کنن . با تشکر از همه


خطای javascript در حالت prod برای فونیکس (حل شد)
#2

داشتم مطالب مربوط به داکرو توی سایت میخوندم که به این مطلب رسیدم و میخواستم بپرسم چرا از docker-compose استفاده کردین؟ آیا چون این روش دیپلوی شما فقط در local هست؟


#3

علت استفاده از docker-compose این بوده که ما منابع کمی داریم و دلیل اصلیش این هست که ما روی vps هستیم که VT-X/AMD-v روش فعال نیست برای همین نمیشه از docker-machine استفاده کرد تا با داریور virtual-box یک vm ساخت و در حالت swarm عمل deploy رو انجام داد. در حال حاضر بهترین راه docker-compose بود . اگر شما روش بهتری برای deploy دارید . خوشحال میشیم عنوان کنید


#4

منظورم docker. Machine نبود، چون docker machine فقط برای تست کردن ساخته شده، منظورم docker stack بود.
نباید از compose در prod استفاده کنید


#5

من برای بردن تو حالت prod از این داکیومنت استفاده کرده بودم

پیش نیاز ها برای docker stack به این صورت هست

Prerequisites

    Install Docker version 1.13 or higher.
    Get Docker Compose as described in Part 3 prerequisites.
    Get Docker Machine as described in Part 4 prerequisites.
    Read the orientation in Part 1.

    Learn how to create containers in Part 2.

    Make sure you have published the friendlyhello image you created by pushing it to a registry. We use that shared image here.

    Be sure your image works as a deployed container. Run this command, slotting in your info for username, repo, and tag: docker run -p 80:80 username/repo:tag, then visit http://localhost/.

    Have a copy of your docker-compose.yml from Part 3 handy.

    Make sure that the machines you set up in part 4 are running and ready. Run docker-machine ls to verify this. If the machines are stopped, run docker-machine start myvm1 to boot the manager, followed by docker-machine start myvm2 to boot the worker.
    Have the swarm you created in part 4 running and ready. Run docker-machine ssh myvm1 "docker node ls" to verify this. If the swarm is up, both nodes report a ready status. If not, reinitialize the swarm and join the worker as described in Set up your swarm.

طبق لینک زیر

من در مورد deploy کردن با docker stack این داکیومنت رو دیدم

ولی بیشتر جاها از swarm صبحت کرده . هنوز تست نکردم ببین چطور هست .

آیا بدون درست کردن vm هم میشه از docker stack استفاده کرد ؟
علت اینکه فرمودین نباید از compose در حالت prod استفاده کرد چی هست ؟


#6

منظورش بیشتر فایل compose در prod هست تا خود docker-compose, شما اصلا در prod حتی نیاز به نصب docker-compose ندارید، خیلی زود یک توضیح درست کامل میدم خدمتتون، چون واقعا فکر می کنم روش کار شما میتونه خیلی خوب تغییر کنه.


#7

الان docker stack رو تست کردم و طبق گفته شما نیاز به vm نداشتم فقط قبلش اینو زدم

sudo docker swarm init

بعد بجای دستور

sudo docker-compose  -f nginx.yml  -f example.yml  -f network.yml  up -d

از دستور زیر استفاده کردم

sudo docker stack  deploy  -c  nginx.yml  -c example.yml  -c network.yml  example.com

البته توی فایلها هنوز تگ deploy با تنظیماتش رو نزاشتم ولی خب دستور مورد نظرکار کرد

فقط یه سوال اینکه من زمانیکه با docker-compose سرویس ها رو ران میکردم میتونستم یک کانتینر رو استپ بزنم و دوباره ران کنم ولی اینجا توی docker stack من دستور استپ برای اینکه یک سرویس رو فقط متوقف کنم پیدا نکردم .

تشکر . لطف میکنید .


#8

حتما از تگ deploy استفاده کن که به مشکلات عجیب بر نخوری.
درضمن میتونی روی ماشین خودت با فرمان docker-compose config از اون فایل ها یک فایل بسازی، فکر کنم تا حالا خودت رفته باشی سراغش.


#9

اره حتما اون رو میزارم با تنظیماتی که باید انجام بشه. یه سری سوال برام پیش اومده. فعلا صبر میکنم چون ممکنه جواب ها در توضیحات شما که بعدا میخواین بدین باشه


#10

صبح حتما میام و پاسخ میدم، چون ممکنه سوال شما سوال من هم باشه و باعث بشه مجبور بشم تحقیق کنم :+1:


#11

فقط به عنوان پاسخ کوتاه به گزینه های docker service ls و docker service ps service_name توجه کنید و البته docker service —help


#12

درسته توی sudo docker service بود همه مواردی که نیاز داشتم :pray:


#13

سلام
من یه مقدار تست کردم swarm و stack رو مشکل خاصی نداشتم . بجز مشکل ip استاتیک که روش اعمال نمیشه . یعنی اگر ip استاتیک توی فایل docker-compose.yml هم باشه باز خودش ip دیگه ای میده

توی این پست هم در موردش صحبت کردن


#14

سلام، ببخشید من قرار بود پست بزارم اما اصلا فرصت نشده هنوز.
در prod چه نیازی به static ip دارید؟ کار swarm فقط اجرای سرویس ها نیست، load blancing و scale کردن به روش اضافه کردن تعداد بیشتر کانتینر برای هر سرویس چیزیه که در نهایت واژه swarm هم از همون اومده، یعنی یک swarm از کانتینر ها برای سرویس ها، با توجه به این موضوع اصلا static ip عملی بنظر میاد؟ یا اگر عملی باشه آیا اصلا بدرد میخوره؟

باید توجه داشته باشی که در مورد prod حرف می زنیم و swarm اصلا بدر dev نمی خوره. من در تست سرور، uat و prod از swarm استفاده می کنم چون هر سه شبیه prod هستند اما در سیستم خودم از docker-compose
اگر بتونی دقیقا مورد استفاده رو بگی شاید بتونم بهتر کمک کنم، شایدم گفتی من یادم نیست😖. گاهی یک ضعف کوچیک در روش کار یا نگرش ما، مشکلاتی بوجود میاره که همه چیز به سمت سمبل کاری میره (work around) و همینطور جلو میریم😁 اما بعد متوجه می شیم که راه بهتر و ساده تری وجود داره.

بنظر من بهتره پرنده های زیر با گونه، جنسیت و مسیر پروازشون دسته بندی بشند، تا اینکه هر پرنده اسم خاص خودشو در گله داشته باشه چون با نام دهی انفرادی، به ازای هر پرنده یک مشکل به مشکلات اضافه میشه! (این فقط یک مثال در مورد static ip بود، در swarm هم هر کانتینر اسم و id مخصوص خودشو داره)

Swarm :point_down::point_down::point_down:
image


#15

من ip استاتیک رو برای ۳ کانتینر نیاز دارم
کانتینر اول ایمیل که توش سرویس dovecot و postfix بود که اون رو با یه اسکریپت حل کردم البته اگر راه بهتری هم باشه ازش استفاده میکنم
چون سرویس های ایمیل من باید با کانتینر postgres در ارتباط باشن توی فایل تنظیماتشون فقط میشه ip مشخص کرد و نمیتونم اسم کانتینر یا رو بدم . برای همین اگر ip بدم و ثابت نباشه زمانیکه سرور به هر دلیلی ریست بشه یا کانتینرها رو دوباره لود کنم ip عوض میشه و دچار مشکل میشم فعلا که با شل حل شده

کانتینر دوم خوده postgres هست و فایل pg_hba.conf هست که توی اون دسترسی شبکه و اتصالات به خودش رو محدود میکنه که من اونجا به این صورت عمل کردم

# TYPE  DATABASE        USER            ADDRESS                 METHOD
#------------------------------------------------------------------------
host  cms_user      container_cms      172.25.20.0/24           md5
host  dovecot_user  container_dovecot  172.25.30.0/24           md5
host  dovecot_user  email_reader       172.25.30.0/24           md5
host  dovecot_user  email_writer       172.25.30.0/24           md5
host  email_user    email_user         172.25.40.0/24           md5
host  users_user    users              172.25.50.0/24           md5

کانتینر سوم مربوط به redis هست که من توی تنظیمات قسمت bind رو ip خود کانتینر قرار دادم که اینجا هم اسم کانتینر رو نمیتونم قرار بدم


#16

۱- باید از اسم سرویس استفاده کنید نه کانتینر، اگر همه در یک swarm باشند مشکل دسترسی حل میشه. منظورم از اسم سرویس در yml فایل هست. Overley Network

۲- با دادن ip به این شکل عملا امکان scale شدن اون سرویس ها که نام بردین از بین میره.


#17

منظور از اسم سرویس یعنی این فیلد؟

container_name: pgadmin

چون من همینو پینگ میکنم ip کانتینر رو به من میده


#18

اون اسم کانتینر هست
شما در فایل yml یه services: دارید که زیرش هر سرویس با نام خودش namespace شده

version: “3”
services:
    admin:
        image: image_name
    database:
        Blah blah blah
    redis:
        Blah blah blah

Service name => admin
Service name => database
Service name => redis

توجه کن که منظورم service name ای نیست که swarm در سیستم درست میکنه


#19

خب اسم سرویس و اسم کانتینر من یکی هست به این صورت

services:     
  my_postgres:
    image: mojtabanaserei/postgresql:10.5
    container_name: my_postgres
    .
    .
    .

  my_redis:
    image: mojtabanaserei/redis:4.0.11
    container_name: my_redis
    .
    .
    .
    .

#20

چه نیازی به container_name هست اصلا؟ هر سرویس ممکنه چنتا کانتینر داشته باشه