این مساله در علوم کامپیوتر به حالتی گفته میشود که یک cache که بسیار پراستفاده است منقضی میشود و همزمان تعداد بسیار زیادی از درخواست برای آن ارسال شده و در نتیجه چون منقضیست تمامی این درخواستها به دیتابیس ارسال میشود و موجب ازدحام دیتابیس میشود.
تنها در سیستمهایی این مشکل ایجاد میشود که سرویس مربوطه تنها با استفاده از cache دارای performance خوبی شده و قابل استفاده است و در این حالت دیگر سیستم قابل استفاده نخواهد بود.
در علوم کامپیوتر مساله ای مطرح است به نام “گله ی رعد آسا” یا Thundering Herd Problem.
وقتی که تعداد زیادی process منتظر یک رخداد یا event هستند، ولی وقتی که این event رخ داد تنها یکی از این process ها باید انجام گیرد. در این حالت بعد از رخداد یک process انجام میگردد و باقی آنها معطل میشوند و یا مکررا دوباره تلاش میکنند و در نتیجه سیستم هنگ میکند. این در حالیست که تنها یکی از آنها باید اجرا میشدند و باقی باید کنسل میشدند.
در UNIX این مشکل به این شکل حل شده است: همه پاسخها در یک file descriptor نوشته می شوند بنابراین پس از پاسخ تنها یکی از process ها یا thread ها اجرا میشوند (بجای اینکه همگی با هم اجرا و سیستم هنگ کند)
مثال دیگر:
فرض کنید یک API داریم و 500 پروسه این API را صدا میزنند. ولی این سرویس تنها میتواند 2 تای آنها را پاسخ دهد. و 488 مورد دیگر Fail می شوند. ولی دوباره تلاش میکنند و این بار این سرویس با 996 درخواست روبروست و مجددا تنها میتواند 2 تای آنها را پاسخ دهد و این سیکل تا زمانی ادامه پیدا میکند که سرویس مختل شود. این هم مثال دیگری از گله ی رعد آساست.
برای حل این مشکل راه حل این است که از فراخوانی اگر Fail شد پس از 2 به توان N ثانیه دوباره تلاش کند. بنابراین دفعه دوم بعد از 4 واحد زمانی سپس 8 ، 16 و… واحد زمانی دوباره تلاش میکند این فاصله زمانی که تابع نمایی exponential هست موجب می شود که سرویس فرصت بازسازی خود را داشته باشد. در ادامه این راه حل میتوان یک عدد تصادفی به عنوان jitter به این بازه زمانی اضافه کرد تا همه فراخوانی ها دوباره همزمان نشوند. یعنی فرمول فراخوانی مجدد میشود (T + 2**N + JITTER)
از دیتابیس MySQL بک آپ گرفتیم به صورتی که این دیتابیس توی یک Docker Container بود که دیتای اون مپ شده به آدرس زیر. بنابراین با بک آپ از /var/lib/mysql تمامی دیتای این دیتابیس بک آپ گرفته میشه و میتونیم بعدا برداریم.
علاوه بر اون با استفاده از mysqldump هم از کل دیتابیس ها یک بک آپ توی فرمت sql گرفتم برای محکم کاری.
از طرفی این دیتا مربوط به یک وب اپلیکیشن هست که فایلهای آپلود شده و آواتارها و هر چیزی که آدرسش توی دیتابیس هست اما خود فایل توی /project/uploads ذخیره شده. بنابراین باید از این مسیر هم یک بک آپ بگیریم. نتیجه شد اسکریپت زیر:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 |
timestamp=$(date +"%Y%m%d_%H%M%S") backup_dir="/home/backup" filesystem_filename_backup="mysql_data_backup_FS_${timestamp}.tar.gz" mysql_backup_file="mysql_data_backup_DUMP_${timestamp}.sql" media_backup_file="media_files_backup_${timestamp}.tar.gz" docker run --rm --volumes-from mysql -v ${backup_dir}/:/backup busybox tar cvfz backup/${filesystem_filename_backup} --directory=/var/lib/mysql . if [ $? -eq 0 ]; then echo "backup successfull: ${filesystem_filename_backup}" else echo "Error" exit 1 fi echo "Starting MySQL backup..." docker exec mysql mysqldump -u root -p'yourpassword' --all-databases > ${backup_dir}/${mysql_backup_file} if [ $? -eq 0 ]; then echo "MySQL backup successful: ${mysql_backup_file}" else echo "MySQL backup failed!" exit 1 fi echo "Starting media files backup..." tar -czf ${backup_dir}/${media_backup_file} -C /project/uploads . if [ $? -eq 0 ]; then echo "Media files backup successful: ${media_backup_file}" else echo "Media files backup failed!" exit 1 fi echo "Backup completed successfully!" |
برای اینکه سرویس از https استفاده کند باید چند کار انجام دهیم.
1.فایل های certificate را در سرور بسازیم
2.درخواستهای http را به https ارجاع دهیم
3.تنظیمات https را در nginx تنظیم کنیم
4.در برنامه هرجا لازم است تغییراتی انجام میدهیم مثلا اگر تا الان از وب سوکت ws استفاده میشده باید الان از wss استفاده شود.
حواسمون باشه فایل های cert و key کلیدها باید با رشته های زیر تعریف شوند:
|
1 2 3 4 5 6 |
-----BEGIN PRIVATE KEY----- -----END PRIVATE KEY----- -----BEGIN CERTIFICATE----- -----END CERTIFICATE----- |
برای این تنظیمات در داکری که یه سری سرویس دارد از تنظیمات زیر استفاده میکنیم:
nginx.conf
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 |
events { worker_connections 1024; } http { include /etc/nginx/mime.types; default_type application/octet-stream; sendfile on; keepalive_timeout 65; client_header_timeout 600s; client_body_timeout 600s; send_timeout 600s; client_max_body_size 50M; proxy_buffers 4 256k; proxy_buffer_size 256k; proxy_busy_buffers_size 256k; client_header_buffer_size 512k; large_client_header_buffers 4 256k; proxy_connect_timeout 600s; proxy_read_timeout 600s; proxy_send_timeout 600s; #HTTP server Block server { listen 80; server_name hivadar.ir; # Redirect HTTP to HTTPS location / { return 301 https://$host$request_uri; } } #HTTPS Server server { listen 443 ssl; server_name hivadar.ir; # SSL Configuration ssl_certificate /etc/nginx/server.crt; ssl_certificate_key /etc/nginx/server.key; # Strong SSL protocols and ciphers # ssl_protocols TLSv1.2 TLSv1.3; # ssl_prefer_server_ciphers on; # ssl_ciphers HIGH:!aNULL:!MD5; # HSTS (optional): Forces HTTPS for future requests # add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always; location / { proxy_pass http://uwsgi-container:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } location /ws/ { proxy_pass http://daphne-container:8001; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } location /static/ { alias /static/; } } } |
فایل compose داکر
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 |
version: '3.8' services: uwsgi-container: image: nasimproject-nasim:latest #build: # context: . # dockerfile: ... hostname: nasim container_name: nasim volumes: - ./app:/opt/app - ./data:/opt/data expose: - "8000" environment: - DJANGO_SETTINGS_MODULE=core.settings command: > uwsgi --http 0.0.0.0:8000 --module core.wsgi:application --master --processes 4 --threads 4 --buffer-size 163840 --http-timeout 300 --harakiri 300 daphne: #image: project-daphne:latest build: context: . dockerfile: ... hostname: daphne container_name: daphne volumes: - ./app:/opt/app - ./data:/opt/data expose: - "8001" environment: - DJANGO_SETTINGS_MODULE=core.settings nginx: image: project-nginx:latest #build: # context: . # dockerfile: ... hostname: nginx container_name: nginx ports: - "80:80" - "443:443" depends_on: - uwsgi-container - daphne volumes: - ./app/static:/static - ./nginx/nginx.conf:/etc/nginx/nginx.conf - ./nginx/certs/server.crt:/etc/nginx/server.crt - ./nginx/certs/server.key:/etc/nginx/server.key rabbit: hostname: rabbit container_name: rabbit image: rabbitmq:3-management environment: - RABBITMQ_DEFAULT_USER=... - RABBITMQ_DEFAULT_PASS=... ports: - "5672:5672" - "15672:15672" celery: build: context: . dockerfile: DockerfileCelery hostname: celery container_name: celery volumes: - ./app:/opt/app beat: build: context: . dockerfile: DockerfileBeat hostname: beat container_name: beat volumes: - ./app:/opt/app |
مجموعه دستورات پر استفاده کار با داکر
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 |
Install Ubuntu 22.04 apt update apt install docker.io == docker images docker ps vim /etc/apt/resolve.conf nameserver 10.202.10.202 #shekan docker pull alpine:latest docker load -i /path/alpine.tar #create container based on alpine docker run -dit --name alp1 alpine docker exec alp2 ip a docker exec alp2 ping .. docker attach alp2 CTRL+p+q ls /var/lib/docker ls /var/lib/docker/containers usermod -aG docker user1 service docker restart docker start alp1 docker ps brctl show #list all bridge docker network ls docker network create mynet docker run -dit -name alp3 --net mynet alpine docker run -dit --name alp4 --net mynet alpine docker exec alp3 ping alp4 docker network inspect mynet docker run -dit --name mynginx nginx:alpine docker rm -f mynginx docker run -dit --name mynginx nginx:alpine 80:80 ################################# 192.168.56.1 ZDsoft recorder ----------------------------------- docker images docker pull nginx:alpine scp .... docker load -i /home/nginx-alpine.tar docker images mkdir project1 cd project1 echo MySite > index.html nano DockerFile from nginx:alpine copy index.html /usr/share/www/index.html docker build -t web . docker ps docker run -dit --name mynginx -p 80:80 nginx:alpine docker ps docker rm -f mynginx docker run -dit --name mynginx -p 80:80 web docker ps docker network create mynet docker run -dit --name alp3 mynet alpine docker run -dit --name alp4 mynet alpine docker exec alp4 ip a docker exec alp4 ping 172.18.0.2 docker exec alp4 ping alp3 docker exec alp4 ping alp1 # name discovery on user defined bridge iptables -I DOCKER-USER -i docker0 -o br-fc... -j ACCEPT iptables -I DOCKER-USER -o docker0 -i br-fc... -j ACCEPT docker exec alp4 ping alp1 docker netwrok inspect docker rm -f mynginx docker run -dit --name mynginx --net host web # no need to publish port like 80:80 because its on host network ---------------- docker network create -d macvlan --subnet 192.168.93.0 --iprange 192.168.93.192/26 -o parent ens33 --gateway 192.168.93.2 macvlan1 docker run -dit --name alp5 --net macvlan alpine docker exec alp5 ip a docker network inspect macvlan1 ---------------- ip netns add ns1 ip netns add ns2 ip link add veth0 ip -n ns0 link ip netns ip link ip netns add ns0 ip -n ns0 link clear ip netns add ns1 ip link add veth0 type veth peer name veth1 ip link clear ip link set veth0 netns ns0 ip -n ns0 link ip link set veth1 netns ns1 ip -n ns0 link set veth0 up ip -n ns0 link set lo up ip -n ns0 addr add 10.0.1.1/24 dev veth0 ip -n ns1 link set veth1 up ip -n ns1 link set lo up ip -n ns1 addr add 10.0.2.1/24 dev veth1 ip -n ns0 a clear ip netns exec ns0 ping 10.0.2.1 ip -n ns0 route add 10.0.2.0/24 dev veth0 ip -n ns1 route add 10.0.1.0/24 dev veth1 ip netns exec ns0 ping 10.0.2.1 clear history ip netns |
برای پیاده سازی Odoo توی داکر باید اول docker-compose.yml رو داشته باشیم:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 |
version: '3.1' services: odoo: build: context: ./odoo dockerfile: Dockerfile container_name: odoo17 ports: - "8069:8069" volumes: - odoo-data:/var/lib/odoo - ./odoo/odoo17.conf:/etc/odoo17.conf - ./odoo/odoo-custom-addons:/opt/odoo17/odoo-custom-addons environment: - HOST=odoo17-db - USER=odoo17 - PASSWORD=odoo17 depends_on: - db user: "odoo17:odoo17" db: build: context: ./postgres dockerfile: Dockerfile container_name: odoo17-db environment: - POSTGRES_USER=odoo17 - POSTGRES_PASSWORD=odoo17 - POSTGRES_DB=postgres volumes: - db-data:/var/lib/postgresql/data volumes: odoo-data: db-data: |
داکرفایل postgress:
|
1 2 |
FROM library/postgres COPY init.sql /docker-entrypoint-initdb.d/ |
یه فایل init.sql هم استفاده شده:
|
1 |
CREATE USER odoo17 IDENTIFIED BY odoo17; |
فایل odoo17.conf
|
1 2 3 4 5 6 7 8 |
[options] admin_passwd = amir db_host = odoo17-db db_port = 5432 db_user = odoo17 db_password = odoo17 addons_path = /opt/odoo17/odoo/addons,/opt/odoo17/odoo-custom-addons logfile = /var/log/odoo/odoo.log |
از همه مهمتر Dockerfile خود Odoo:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 |
# Use an official Python runtime as a parent image FROM python:3.11-slim # Set environment variables ENV LANG=C.UTF-8 LC_ALL=C.UTF-8 # Install required packages and dependencies RUN apt-get update && apt-get install -y --fix-missing \ git \ build-essential \ wget \ python3-dev \ libfreetype6-dev \ libxml2-dev \ libzip-dev \ libldap2-dev \ libsasl2-dev \ node-less \ libjpeg62-turbo-dev \ zlib1g-dev \ libpq-dev \ libxslt1-dev \ libtiff5-dev \ libopenjp2-7-dev \ liblcms2-dev \ libwebp-dev \ libharfbuzz-dev \ libfribidi-dev \ libxcb1-dev \ && apt-get clean \ && rm -rf /var/lib/apt/lists/* # Create Odoo user and group RUN groupadd -r odoo17 && useradd -m -d /opt/odoo17 -g odoo17 -s /bin/bash odoo17 # Switch to Odoo user USER odoo17 # Set working directory WORKDIR /opt/odoo17 # Clone Odoo source code RUN git clone --depth 1 --branch 17.0 https://www.github.com/odoo/odoo /opt/odoo17/odoo # Create and activate a virtual environment, then install dependencies RUN python3 -m venv odoo-venv && \ /bin/bash -c "source odoo-venv/bin/activate && pip install wheel && pip install -r /opt/odoo17/odoo/requirements.txt" # Create custom addons directory RUN mkdir /opt/odoo17/odoo-custom-addons # Copy Odoo configuration file COPY odoo17.conf /etc/odoo17.conf # Expose Odoo port EXPOSE 8069 # Define the command to run the Odoo server CMD ["/opt/odoo17/odoo-venv/bin/python3", "/opt/odoo17/odoo/odoo-bin", "-c", "/etc/odoo17.conf"] |
در نرم افزاری طول URL از حدی که بیشتر میشد سرور ارور بر میگردوند. با بررسی لاگ Nginx و uWSIG متوجه شدم که سایز هدری که مرورگر میفرسته از حدی بیشتره و سرور قبول نمیکنه. از طرفی اون عملیات زمان بر هم بود و وقتی که سایز هدر را هم بیشتر کردم باز هم چون طول میکشید سرور کانکشن رو میبست. با تنظیمات Nginx زیر تونستم هم طول هدر رو بیشتر کنم هم مدت زمان کانکشن ها:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 |
events { worker_connections 1024; } http { include /etc/nginx/mime.types; default_type application/octet-stream; sendfile on; keepalive_timeout 65; client_header_timeout 600s; client_body_timeout 600s; send_timeout 600s; # limits the size of the client request body client_max_body_size 50M; # These parameters control the buffer sizes used by NGINX when proxying responses from the upstream (uWSGI). Increasing buffer sizes allows NGINX to handle larger responses without having to offload data to disk proxy_buffers 4 256k; proxy_buffer_size 256k; proxy_busy_buffers_size 256k; # Increase buffer sizes to handle long URLs client_header_buffer_size 512k; large_client_header_buffers 4 256k; # This is the time NGINX waits for uWSGI proxy_connect_timeout 600s; proxy_read_timeout 600s; proxy_send_timeout 600s; # upstream myuwsgi { # server myuwsgi:8000; # } server { listen 80; location / { proxy_pass http://myuwsgi:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } location /ws/ { proxy_pass http://daphne:8001; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } location /static/ { alias /static/; } } } |
فایل compose کل سرویس ها هم مثل زیره:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 |
version: '3.8' services: nasim: image: myuwsgiproject:latest #build: # context: . # dockerfile: Dockerfile hostname: uwsgiproject container_name: uwsgiproject volumes: - ./app:/opt/app - ./data:/opt/data expose: - "8000" environment: - DJANGO_SETTINGS_MODULE=core.settings command: > uwsgi --http 0.0.0.0:8000 --module core.wsgi:application --master --processes 4 --threads 4 --buffer-size 163840 --http-timeout 300 --harakiri 300 daphne: #image: nasimproject-daphne:latest build: context: . dockerfile: DockerfileDaphne hostname: daphne container_name: daphne volumes: - ./app:/opt/app - ./data:/opt/data expose: - "8001" environment: - DJANGO_SETTINGS_MODULE=core.settings nginx: image: uwsgiproject-nginx:latest #build: # context: . # dockerfile: DockerfileNginx hostname: nginx container_name: nginx ports: - "80:80" depends_on: - nasim - daphne volumes: - ./app/static:/static - ./nginx/nginx.conf:/etc/nginx/nginx.conf rabbit: hostname: rabbit container_name: rabbit image: rabbitmq:3-management environment: - RABBITMQ_DEFAULT_USER= - RABBITMQ_DEFAULT_PASS= ports: - "5672:5672" - "15672:15672" celery: build: context: . dockerfile: DockerfileCelery hostname: celery container_name: celery volumes: - ./app:/opt/app beat: build: context: . dockerfile: DockerfileBeat hostname: beat container_name: beat volumes: - ./app:/opt/app |
قبلا Nginx و uWSGI رو به صورت زیر اجرا کرده بودم که وقتی طول URL زیاد میشد ارور 502 میگرفتم. ارور رو بررسی که کردم دیدم uWSGI ارور میده. و ماکسیموم طول هدر برابر است با 4096 ولی طول این url بیشتره. Nginx رو به صورت زیر اجرا کرده بودم.
nginx.conf
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 |
# nginx/nginx.conf events { worker_connections 1024; } http { include /etc/nginx/mime.types; default_type application/octet-stream; sendfile on; keepalive_timeout 65; # Increase client body buffer and header buffer sizes client_max_body_size 10M; # Increase if necessary large_client_header_buffers 4 16k; upstream myproject { server myproject:8000; } server { listen 80; location / { proxy_pass http://myproject; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } location /ws/ { proxy_pass http://daphne:8001; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } location /static/ { alias /static/; } } } |
و Dockerfile ای که مربوط به uWSGI هست به صورت زیر اجرا شده بود:
|
1 |
CMD ["uwsgi", "--socket", "0.0.0.0:8000", "--module", "core.wsgi:application", "--master", "--processes", "4", "--threads", "4"] |
بعد –buffer-size رو بهش اضافه کردم که درست بشه
|
1 |
CMD ["uwsgi", "--socket", "/opt/app/uwsgi.sock", "--chmod-socket=666", "--module", "core.wsgi:application", "--master", "--processes", "4", "--threads", "4", "--buffer-size", "8192"] |
اما مشکل حل نشد. مشکل اینجا بود که Nginx به صورت پراکسی کل درخواست http رو به uWSGI میفرسته ولی بهتره که درخواست رو خودش پردازش کنه و بعد روی socket درخواست رو به uWSGI بده چون اون پروتکل wsgi رو بهتر و با پرفورمنس بهتر مدیریت میکنه.
قبلا uWSGI هم درخواست های http رو پردازش میکرد هم به عنوان یک application server درخواست های wsgi رو مدیریت میکرد یعنی Nginx یک reverse proxy معمولی بود ولی بهتره که http رو nginx مدیریت کنه و uWSGI به عنوان application server کار کنه که این از نظر پرفورمنس بهتره.
حالا که uWSGI رو روی socker کانفیگ کردیم باید Nginx هم درخواست ها رو روی socket بگیره و بده. بنابراین تنظیمات جدید به صورت زیر میشه:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 |
events { worker_connections 1024; } http { include /etc/nginx/mime.types; default_type application/octet-stream; sendfile on; keepalive_timeout 65; # Increase client body buffer and header buffer sizes client_max_body_size 10M; # Increase if necessary large_client_header_buffers 4 16k; upstream myproject { # Connect to the uWSGI app via Unix socket server unix:/opt/app/uwsgi.sock; } server { listen 80; location / { # Forward requests to uWSGI socket uwsgi_pass myproject; include /etc/nginx/uwsgi_params; # Set proxy headers proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } location /ws/ { # Forward WebSocket requests to Daphne proxy_pass http://daphne:8001; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } location /static/ { alias /static/; } } } |
ASCII یک استاندارد کدگذاری داده هاست که توی ارتباطات کاربرد داره. این استانداره 128 کاراکتر داره که 95 عدد اون نوشتنی هستند. جدول زیر نشون دهنده کاراکترهای این استاندارد هستند.
بایناری که همان دودویی هست نقش مهمی توی کامپیوتر بازی میکنه خیلی از فایلها محتوای دودویی دارن مثل عکس ویدیو و pdf و هر فایل دیگه ای. علاوه بر همه اینها ممکنه توی یک برنامه یک آبجکت یا داده ساختار هم باشه که طبیعتا این هم دودویی هست. شامل 0 و 1
نکته مهم اینه که خیلی از پروتکل های ارتباطی قابلیت ارسال محتوای دودویی رو ندارن مثل HTTP یا SMTP یعنی اگر یک ایمیل داشته باشید نمیتونید باهاش فایل بایناری بفرستید. ولی ما همه تست کردیم و شده چراکه اون اپلیکیشن ایمیل اول اون فایل دودویی رو به یک استاندارد دیگه تبدیل میکنه و میفرسته و در مقصد هم اون رو دوباره به دودویی تبدیل میکنه و تحویل گیرنده میده. چراکه پروتکل های گفته شده بر اساس تکست کار میکنن محتوایی که قابل پرینت شدن باشن نه دودویی. بنابراین اگر از طریق این پروتکل ها یا توی JSON بخوایم یک محتوای دودویی بفرستیم اول باید به تکست encode بشه بعد توی مقسد از تکست به بایناری decode بشه.
استانداردی که برای این کار استفاده میشه Base64 هست. Base64 مخصوص تبدیل کردن محتوای دودویی به ASCII های قابل چاپ هست. کاراکترهای موجود در Base64 شامل A تا Z به اضافه a تا z به اضافه 0 تا 9 به اضافه + / = هستند. یعنی از 000000 تا 111111 رو شامل میشه بنابراین هر بایت به یک کاراکتر تبدیل میشه و میتونیم روی وب یا پروتکل های دیگه که بر اساس تکست کار میکنن بفرستیم.
آیا فرستادن فایل های بایناری روی وب و تبدیل به Base64 کار خوبیه؟ کاربردهایش چیه؟
1.اتچ کردن فایل بایناری توی ایمیل
2.ارسال فایل بایناری روی HTTP یا SMTP با JSON یا XML
3.ذخیره کردن آبجکتهای کوچیک بایناری توی فایل متنی
4.امبد کردن فایل های بایناری مثل عکس توی HTMLیا CSS
استفاده از Base64 حدود 33 درصد افزایش حجم خواهد داشت بنابراین استفاده از این برای فایل بزرگ توصیه نمیشه. برای فایلهای حجیم باید فایل مستقیم بدون encodeشدن از سرور دانلود شه چرا که تبدیل حجم زیاد خودش از هر نظر هزینه بر هست و فایل حجیم هم نیازی نیست که توی HTML بخوایم امبد کنیم و بهتره لینک دانلود بدیم یا استریم کنیم.
حالا ما میخوایم یک فایل pdf توی بروزر نشون بدیم یک راه حل اینه که فایل رو مستقیم لینک بدیم توی فرانت اند از pdf viewer خود بروزر استفاده کنیم یا iframe چون این دوتا میتونن فایل pdf که بایناری هست رو نشون بدن.
به دلایلی من تصمیم گرفتم که pdf رو هر صفحه شو به یک عکس تبدیل کنم و توی فرانت نشون بدم آیا میتونم این کار رو بکنم. HTTP میتونه فایل بایناری بفرسته ولی توی HTML نمیتونم فایل بایناری امبد کنم اصلا base64 برای همین اختراع شده که تبدیلش کنم به base64 که توی html قرار بگیره.
حالا میتونم توی بک اند تبدلیش کنم به base64 و بفرستم سمت فرانت و فرانت مستقیم بزاره توی html یا میتونم pdf رو به صورت بایناری بفرستم فرانت و اونجا base64 اش کنم و توی فرانت بزارم توی html. ترجیه میدم توی بک اند این کار رو بکنم.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 |
def extract_page_to_base64(request, input_pdf, page_number): with input_pdf.open('rb') as file: reader = PdfReader(file) writer = PdfWriter() total_pages = len(reader.pages) if page_number >= total_pages or page_number < 0: page_number = 0 content_page = reader.pages[page_number] mediabox = content_page.mediabox page_width, page_height = letter # Letter size (8.5 x 11 inches) text_pattern_pdf = create_text_pattern(str(request.user), page_width, page_height) reader_pattern = PdfReader(BytesIO(text_pattern_pdf.read())) pattern_page = reader_pattern.pages[0] pdf_file_path = get_watermark_pdf_path() reader_stamp = PdfReader(pdf_file_path) image_page = reader_stamp.pages[0] image_page.merge_page(content_page) image_page.merge_page(pattern_page) image_page.mediabox = mediabox writer.add_page(image_page) temp_output = BytesIO() writer.write(temp_output) temp_output.seek(0) encoded_pdf = base64.b64encode(temp_output.read()).decode('utf-8') return encoded_pdf |
توی کد بالا یک صفحه از pdf رو میگیره و از بایناری تبدیلش میکنه به Base64 که برای امبد شدن توی HTML خوبه و میفرسته و ابته قبل از فرستادن تبدیل میکنه به utf-8 و این دیگه چیه؟
مساله اینجاست که تابع bs64encode فایل بایناری رو به کاراکترهای Base64 تبدیل میکنه ولی هنوز هم تایپش بایناریه یعنی مقدارش کاراکتر base64 ولی وقتی میزنیم print(type(… میبینیم که بایناری هست نوعش مثل b’VGhpcyBpcyBhIGJhc2U2NCBlbmNvZGVkIHN0cmluZw==’
خوب این مشکلش چیه توی پایتون مشکلی پیش نمیاد چون ظاهرا پایتون میخات بفرسته تبدلیش میکنه به str ولی برای اینکه explicit باشیم باید به utf-8 اونو دیکد کنیم که دیگه تایپش هم str بشه. در ضمن بروزر های مدرن هم این تبدیل رو خودشون ظاهرا هوشمندانه انجام میدن.
ببینید ما اول بایناری رو تبدیل کردیم به base64 و همینطور که توی جدول ها معلومه base64 خودش زیرمجموعه ASCII هست و از طرفی خود ASCII زیرمتجموعه UTF-8 هست بنابراین توی این کیس مشکل خاصی هم پیش نمیاد. ولی اگر تبدیل برعکس باشه ممکنه مشکل ایجاد بشه.
حالا که همه چی اوکی هست چرا نهایتا باید تبدیل کنیم به utf-8 وقتی که خود بروزر و پایتون می فهمند که string هستن.
1.باید Explicit باشیم. شاید در آینده مشکلی پیش بیاد بهتره مستقیم خودمون تبدیل کنیم به utf-8 که تبدیل به string بشه
2.رشته string و utf-8 استاندارد وب هست. وقتی با وب کار میکنیم همیشه تبدیل کنیم به utf-8
3.شاید یک اپلیکیشن یا بروزر صراحتا به string بودن داده گیر بده پس استاندارد وب رو رعایت کنیم
پینوشت خود utf-8 چیه؟
utf-8 استاندارد کد کردن محتوا و بیشترین انطباق رو با unicode داره یعنی خیالمون راحته که اکثر زبانها و کاراکتر های چاپی و غیرچاپی رو شامل میشه. توسط بیشتر از 95 درصد مرورگرها پشتیبانی میشه و Unix هم کاملا باهاش کار میکنه. پس از این به بعد خواستیم داده ای انتقال بدیم بهتره تبدیل کنیم به utf-8.
اگر بایناری بود اول تبدیل کنیم به base64 که از بایناری به محتوای متنی تبدیل بشه بعد تبدیلش کنیم به utf-8 که توی بهترین استاندارد و در type یک رشته string باهاش کار کنیم.
بعد از نصب داکر فایلهای مورد استفاده خود داکر از قبلی image هایی که load میکنید توی مسیر /var/lib/docker ذخیره میشه که میتونه بعد از مدتی پر شه یا اصلا شاید بخاید جای دیگه ای ذخیره بشه. من خودم چون پارتیشن دیگه ای با حجم بیشتر دارم خواستم یه دایرکتوری دیگه رو map کنم به این دایرکتوری. البته روش های مختلفی وجود داره برای تغییر مسیر اما بهترین روش با کمترین impact این روشه:
|
1 2 |
sudo mkdir /mnt/docker sudo mount --rbind /mnt/docker /var/lib/docker |