GALAXY TECH
Chuyên gia Công nghệ
Thứ sáu, 25/10/2019 | 00:00 GMT+7

Cách tạo ứng dụng Django và Gunicorn với Docker

Django là một khung công tác web mạnh mẽ có thể giúp bạn khởi động ứng dụng Python của bạn một cách nhanh chóng. Nó bao gồm một số tính năng tiện lợi như trình ánh xạ quan hệ đối tượng , xác thực user và giao diện quản trị có thể tùy chỉnh cho ứng dụng của bạn. Nó cũng bao gồm một khuôn khổ bộ nhớ đệm và khuyến khích thiết kế ứng dụng sạch sẽ thông qua Hệ thống điều phối URL và Mẫu của nó .

Trong hướng dẫn này, bạn sẽ học cách tạo ứng dụng Django Polls có thể mở rộng và di động với các containers Docker. Ngoài ra, ứng dụng Django yêu cầu một số sửa đổi để chạy hiệu quả bên trong containers , như ghi log vào các stream kết quả tiêu chuẩn và tự cấu hình thông qua các biến môi trường được chuyển vào containers . Ngoài ra, việc giảm tải các nội dung tĩnh như JavaScript và CSS stylesheet vào bộ nhớ đối tượng cho phép bạn hợp lý hóa và quản lý tập trung các file này trong môi trường nhiều containers .

Bạn sẽ triển khai những sửa đổi này — lấy cảm hứng từ phương pháp Mười hai nhân tố để xây dựng các ứng dụng web root cloud , có thể mở rộng — trên một ứng dụng Django Polls mẫu. Sau đó, bạn sẽ xây dựng hình ảnh ứng dụng và chạy ứng dụng được chứa trong Docker.

Đến cuối hướng dẫn này, bạn sẽ tổng hợp cài đặt trong Cách cài đặt ứng dụng Django có thể mở rộng . Trong các hướng dẫn tiếp theo của loạt bài này, bạn sẽ học cách sử dụng Docker Compose để ghép nối containers Django với Reverse Proxy Nginx và triển khai kiến trúc này cho một cụm Kubernetes.

Bạn rất nên xem qua hướng dẫn để hiểu những thay đổi bạn đang thực hiện đối với ứng dụng, nhưng nếu bạn muốn bỏ qua, bạn có thể lấy mã đã sửa đổi từ nhánh thăm dò ý kiến của repository GitHub của ứng dụng Polls.

Yêu cầu

Để làm theo hướng dẫn này, bạn cần :

Bước 1 - Tạo Database và User PostgreSQL

Để bắt đầu, ta sẽ kết nối với server PostgreSQL từ version Ubuntu. Sau đó, ta sẽ tạo database PostgreSQL và user cho ứng dụng Django và cấu hình database để hoạt động hiệu quả với Django.

Trước khi kết nối với database từ máy Ubuntu của bạn (không phải containers ứng dụng), ta cần cài đặt gói postgresql-client từ repository Ubuntu. Trước tiên, hãy cập nhật index gói apt local , sau đó download và cài đặt gói:

sudo apt update sudo apt install postgresql-client

Nhấn Y rồi nhấn ENTER khi được yêu cầu bắt đầu download và cài đặt các gói.

Đến đây bạn đã cài đặt ứng dụng client , ta sẽ sử dụng nó để tạo database và user database cho ứng dụng Django của ta .

Để bắt đầu, lấy Tham số kết nối cho cụm của bạn bằng cách chuyển đến Database từ Control panel cloud và nhấp vào database của bạn. Bạn sẽ thấy hộp Chi tiết kết nối chứa một số tham số Kết nối cho cụm của bạn. Ghi lại những điều này.

Quay lại dòng lệnh, đăng nhập vào cụm của bạn bằng các thông tin đăng nhập này và ứng dụng client psql PostgreSQL mà ta vừa cài đặt:

psql -U username -h host -p port -d database --set=sslmode=require

Khi được yêu cầu , hãy nhập password được hiển thị cùng với tên user Postgres và nhấn ENTER .

Bạn sẽ nhận được một dấu nhắc PostgreSQL mà từ đó bạn có thể quản lý database .

Đầu tiên, hãy tạo một database cho dự án của bạn được gọi là polls :

CREATE DATABASE polls;

Lưu ý: Mọi câu lệnh Postgres phải kết thúc bằng dấu chấm phẩy, vì vậy hãy đảm bảo lệnh của bạn kết thúc bằng dấu chấm phẩy nếu bạn đang gặp sự cố.

Bây giờ ta có thể chuyển sang database polls :

\c polls;

Tiếp theo, tạo một user database cho dự án. Đảm bảo chọn một password an toàn:

CREATE USER sammy WITH PASSWORD 'password';

Bây giờ ta sẽ sửa đổi một vài thông số kết nối cho user mà ta vừa tạo. Điều này sẽ tăng tốc hoạt động database để các giá trị chính xác không phải được truy vấn và đặt mỗi khi kết nối được cài đặt .

Ta đang đặt mã hóa mặc định thành UTF-8 , mà Django mong đợi. Ta cũng đang đặt schemas cách ly giao dịch mặc định thành “đọc được commit ”, ngăn chặn việc đọc từ các giao dịch không được commit . Cuối cùng, ta đang đặt múi giờ. Theo mặc định, các dự án Django của ta sẽ được đặt để sử dụng UTC . Đây là tất cả các khuyến nghị từ chính dự án Django .

Nhập các lệnh sau tại dấu nhắc PostgreSQL:

ALTER ROLE sammy SET client_encoding TO 'utf8'; ALTER ROLE sammy SET default_transaction_isolation TO 'read committed'; ALTER ROLE sammy SET timezone TO 'UTC';

Bây giờ ta có thể cấp cho user mới quyền truy cập để quản lý database mới của ta :

GRANT ALL PRIVILEGES ON DATABASE polls TO sammy;

Khi bạn hoàn tất, hãy thoát khỏi dấu nhắc PostgreSQL bằng lệnh :

\q

Một ứng dụng Django, được cấu hình đúng, hiện có thể kết nối và quản lý database này. Trong bước tiếp theo, ta sẽ sao chép mã ứng dụng Polls từ GitHub và xác định rõ ràng các phụ thuộc gói Python của nó.

Bước 2 - Sao chép kho ứng dụng và khai báo phụ thuộc

Để bắt đầu quá trình chứa ứng dụng Django Polls của ta , trước tiên ta sẽ sao chép repository django-polls , chứa mã hoàn chỉnh cho ứng dụng Polls hướng dẫn của dự án Django .

Đăng nhập vào server của bạn, tạo một folder có tên là polls-project và sử dụng git để sao chép kho django-polls từ GitHub:

mkdir polls-project cd polls-project git clone https://github.com/do-community/django-polls.git

Truy cập folder django-polls và liệt kê nội dung repository :

cd django-polls ls 
Output
LICENSE  README.md  manage.py  mysite  polls  templates

Bạn sẽ thấy các đối tượng sau:

  • manage.py : Tiện ích dòng lệnh chính được sử dụng để thao tác ứng dụng.
  • polls : Chứa mã ứng dụng polls .
  • mysite : Chứa mã và cài đặt phạm vi dự án Django.
  • templates : Chứa các file mẫu tùy chỉnh cho giao diện quản trị.

Để tìm hiểu thêm về cấu trúc dự án và file , hãy tham khảo Tạo dự án từ tài liệu chính thức của Django.

Trong folder này, ta cũng sẽ tạo một file có tên là requirements.txt chứa các phụ thuộc Python của ứng dụng Django.

Mở một file có tên là requirements.txt trong trình soạn thảo mà bạn chọn và paste vào các phần phụ thuộc Python sau:

polls-project / django-polls / Request.txt
boto3==1.9.252 botocore==1.12.252 Django==2.2.6 django-storages==1.7.2 docutils==0.15.2 gunicorn==19.9.0 jmespath==0.9.4 psycopg2==2.8.3 python-dateutil==2.8.0 pytz==2019.3 s3transfer==0.2.1 six==1.12.0 sqlparse==0.3.0 urllib3==1.25.6

Ở đây ta cài đặt Django, plugin django-storages để giảm tải nội dung tĩnh vào bộ lưu trữ đối tượng, server gunicorn WSGI, bộ điều hợp psycopg2 PostgreSQL, cũng như một số gói phụ thuộc bổ sung. Lưu ý ta liệt kê và version rõ ràng mọi gói Python mà ứng dụng của ta yêu cầu.

Lưu và đóng file .

Bây giờ ta đã nhân bản ứng dụng và xác định các phụ thuộc của nó, ta có thể chuyển sang sửa đổi nó để có tính di động.

Bước 3 - Làm cho Django có thể cấu hình bằng các biến môi trường

Một trong những đề xuất quan trọng nhất từ phương pháp ứng dụng mười hai yếu tố là extract cấu hình được mã hóa cứng từ cơ sở mã của ứng dụng của bạn. Điều này cho phép bạn dễ dàng thay đổi hành vi của ứng dụng của bạn trong thời gian chạy bằng cách sửa đổi các biến môi trường. Docker và Kubernetes đều đề xuất phương pháp cấu hình containers này, vì vậy ta sẽ điều chỉnh file cài đặt ứng dụng của bạn để sử dụng mẫu này.

Tệp cài đặt chính cho dự án Django của ta ( django-polls/mysite/settings.py ) là một module Python sử dụng cấu trúc dữ liệu root để cấu hình ứng dụng. Theo mặc định, hầu hết các giá trị trong file được mã hóa cứng, nghĩa là bạn phải chỉnh sửa file cấu hình để thay đổi hành vi ứng dụng. Thay vào đó, ta có thể sử dụng hàm getenv của Python trong module os để cấu hình Django đọc các tham số cấu hình từ các biến môi trường local .

Để thực hiện việc này, ta sẽ đi qua settings.py và thay thế các giá trị được mã hóa cứng của từng biến mà ta muốn đặt trong thời gian chạy bằng một lệnh gọi tới os.getenv . Hàm os.getenv đọc giá trị từ một tên biến môi trường được cung cấp. Bạn có thể tùy chọn cung cấp tham số thứ hai với giá trị mặc định sẽ được sử dụng nếu biến môi trường không được đặt.

Điều này cho phép ta cài đặt các biến như sau:

polls-project / django-polls / mysite / settings.py
. . . SECRET_KEY = os.getenv('DJANGO_SECRET_KEY') . . . DEBUG = os.getenv('DJANGO_DEBUG', False) . . .

Đối với SECRET_KEY , Django sẽ tìm kiếm một biến môi trường có tên là DJANGO_SECRET_KEY . Vì điều này không nên được mã hóa cứng và cần phải giống nhau trên các server ứng dụng của ta , ta sẽ muốn đặt điều này ra bên ngoài mà không có giá trị dự phòng. Ta muốn ứng dụng không thành công nếu ta không cung cấp điều này, vì nó có thể dẫn đến sự cố nếu các bản sao khác nhau của ứng dụng của ta sử dụng các khóa khác nhau.

Đối với DEBUG , Django sẽ tìm kiếm một biến môi trường có tên là DJANGO_DEBUG . Tuy nhiên, lần này, ta đã cung cấp một giá trị mặc định sẽ được sử dụng làm dự phòng nếu biến không được đặt. Trong trường hợp này, ta đã chọn đặt DEBUG thành False nếu không có giá trị nào được cung cấp để ta không vô tình làm rò rỉ thông tin nhạy cảm trừ khi biến được cố ý xác định và đặt thành True ..

Để áp dụng kỹ thuật này, hãy mở file polls-project/django-polls/mysite/settings.py trong editor mà bạn chọn và di chuyển qua nó, ngoại hóa các biến sau với các giá trị mặc định được cung cấp:

  • SECRET_KEY = os.getenv('DJANGO_SECRET_KEY')
  • DEBUG = os.getenv('DEBUG', False)
  • ALLOWED_HOSTS = os.getenv('DJANGO_ALLOWED_HOSTS', '127.0.0.1').split(',')

Đối với ALLOWED_HOSTS , ta tìm nạp biến môi trường DJANGO_ALLOWED_HOSTS và chia nó thành một danh sách Python bằng cách sử dụng , làm dấu phân tách. Nếu biến không được đặt, ALLOWED_HOSTS được đặt thành 127.0.0.1 .

Khi bạn đã sửa đổi các biến ở trên, hãy chuyển đến biến DATABASES và cấu hình nó như sau:

polls-project / django-polls / mysite / settings.py
. . .  # Database # https://docs.djangoproject.com/en/2.1/ref/settings/#databases  DATABASES = {      'default': {          'ENGINE': 'django.db.backends.{}'.format(              os.getenv('DATABASE_ENGINE', 'sqlite3')          ),          'NAME': os.getenv('DATABASE_NAME', 'polls'),          'USER': os.getenv('DATABASE_USERNAME', 'myprojectuser'),          'PASSWORD': os.getenv('DATABASE_PASSWORD', 'password'),          'HOST': os.getenv('DATABASE_HOST', '127.0.0.1'),          'PORT': os.getenv('DATABASE_PORT', 5432),          'OPTIONS': json.loads(              os.getenv('DATABASE_OPTIONS', '{}')          ),      }  }  . . .

Điều này sẽ đặt các tham số database default bằng cách sử dụng các biến môi trường.

Đối với DATABASES['default']['OPTIONS'] , ta đã sử dụng json.loads để giải mã hóa một đối tượng JSON được chuyển vào thông qua biến môi trường DATABASE_OPTIONS . Hầu hết thời gian, việc diễn giải các biến môi trường dưới dạng các chuỗi đơn giản giúp bản dịch sang cài đặt Django dễ đọc hơn. Tuy nhiên, trong trường hợp này, có thể truyền trong một cấu trúc dữ liệu tùy ý là có giá trị. Mỗi công cụ database có một tập hợp các tùy chọn hợp lệ duy nhất, vì vậy việc có thể mã hóa một đối tượng JSON với các tham số thích hợp mang lại cho ta tính linh hoạt cao hơn nhiều với chi phí dễ đọc.

Để sử dụng thư viện json , hãy nhập nó ở đầu settings.py :

polls-project / django-polls / mysite / settings.py
""" Django settings for mysite project.  Generated by 'django-admin startproject' using Django 2.1.  For more information on this file, see https://docs.djangoproject.com/en/2.1/topics/settings/  For the full list of settings and their values, see https://docs.djangoproject.com/en/2.1/ref/settings/ """  import os import json . . .

Khu vực khác cần đặc biệt chú ý là DATABASES['default']['NAME'] . Đối với hầu hết các công cụ database , đây là tên database trong hệ quản trị database quan hệ. Mặt khác, nếu bạn đang sử dụng SQLite, NAME được sử dụng để chỉ định file database , vì vậy hãy đảm bảo đặt tham số này cho phù hợp.

Vì file settings.py là mã Python, có nhiều cách khác nhau để bạn có thể xử lý việc đọc các giá trị từ môi trường. Phương pháp ta đã sử dụng ở đây chỉ là một kỹ thuật khả thi để cấu hình bên ngoài từ codebase của bạn.

Trong bước này, ta đã cấu hình các biến cài đặt Django chính theo kiểu chung và di động, bao gồm các tham số database . Trong bước tiếp theo, ta sẽ tiếp tục cấu hình cài đặt cho các file tĩnh như bảng định kiểu Javascript và CSS, ta sẽ tập trung và giảm tải cho dịch vụ lưu trữ đối tượng tương thích với S3.

Bước 4 - Giảm tải tài sản tĩnh

Khi chạy nhiều containers Django trong môi trường production , việc duy trì các version file và nội dung tĩnh cụ thể trên toàn bộ group các containers đang chạy có thể phức tạp. Để hợp lý hóa kiến trúc này, ta có thể tải tất cả các phần tử và trạng thái được chia sẻ sang bộ nhớ ngoài. Thay vì cố gắng giữ cho các mục này đồng bộ giữa các bản sao hoặc triển khai các quy trình backup và tải đảm bảo dữ liệu có sẵn local , ta có thể triển khai quyền truy cập vào các nội dung này dưới dạng dịch vụ có thể truy cập mạng.

Trong bước cuối cùng, ta đã cấu hình Django để ta có thể chuyển các tham số kết nối database thông qua các biến môi trường. Trong bước này, ta sẽ thực hiện tương tự đối với dịch vụ lưu trữ đối tượng của bạn , dịch vụ mà ta sẽ sử dụng để lưu trữ các tài sản tĩnh sẽ được chia sẻ bởi các containers Django.

Gói django-storages cung cấp phần backend lưu trữ từ xa (bao gồm cả lưu trữ đối tượng tương thích với S3) mà Django có thể sử dụng để giảm tải các file . Ta sẽ cấu hình ứng dụng Polls để sử dụng django-storages để tải file tĩnh lên DigitalOcean , như được nêu trong Bước 7 của Cách cài đặt ứng dụng Django có thể mở rộng với Database và không gian được quản lý DigitalOcean . Trong hướng dẫn này, ta sẽ sử dụng DigitalOcean Spaces, nhưng bạn có thể sử dụng bất kỳ nhà cung cấp dịch vụ lưu trữ đối tượng nào tương thích với S3.

Để bắt đầu, ta sẽ thực hiện một số sửa đổi đối với cùng một file django-polls/mysite/settings.py mà ta đã thay đổi trong các bước trước.

Bắt đầu bằng cách mở file mysite/settings.py để chỉnh sửa và thêm ứng dụng storages vào danh sách INSTALLED_APPS của Django:

polls-project / django-polls / mysite / settings.py
. . . INSTALLED_APPS = [     . . .     'django.contrib.staticfiles',     'storages', ] . . .

Các storages ứng dụng được cài đặt thông qua django-storages trong requirements.txt file ta xác định trong Bước 1.

Bây giờ, hãy tìm biến STATIC_URL ở cuối file và thay thế nó bằng khối sau:

polls-project / django-polls / mysite / settings.py
. . .  # Static files (CSS, JavaScript, Images) # https://docs.djangoproject.com/en/2.1/howto/static-files/  # Moving static assets to DigitalOcean Spaces as per: # https://www.digitalocean.com/community/tutorials/how-to-set-up-object-storage-with-django AWS_ACCESS_KEY_ID = os.getenv('STATIC_ACCESS_KEY_ID') AWS_SECRET_ACCESS_KEY = os.getenv('STATIC_SECRET_KEY')  AWS_STORAGE_BUCKET_NAME = os.getenv('STATIC_BUCKET_NAME') AWS_S3_ENDPOINT_URL = os.getenv('STATIC_ENDPOINT_URL') AWS_S3_OBJECT_PARAMETERS = {     'CacheControl': 'max-age=86400', } AWS_LOCATION = 'static' AWS_DEFAULT_ACL = 'public-read'  STATICFILES_STORAGE = 'storages.backends.s3boto3.S3Boto3Storage'  STATIC_URL = '{}/{}/'.format(AWS_S3_ENDPOINT_URL, AWS_LOCATION) STATIC_ROOT = 'static/'

Ta mã hóa các biến cấu hình sau:

  • STATICFILES_STORAGE : Đặt phần backend lưu trữ mà Django sẽ sử dụng để giảm tải các file tĩnh. Phần backend S3Boto3Storage này sẽ hoạt động với bất kỳ chương trình backend nào tương thích với S3, bao gồm cả DigitalOcean Spaces.
  • AWS_S3_OBJECT_PARAMETERS Đặt tiêu đề kiểm soát cache trên các file tĩnh.
  • AWS_LOCATION : Xác định một folder được gọi là static trong group lưu trữ đối tượng, nơi tất cả các file tĩnh sẽ được đặt.
  • ` AWS_DEFAULT_ACL : Xác định danh sách kiểm soát truy cập (ACL) cho các file tĩnh. Đặt nó ở public-read đảm bảo user cuối có thể truy cập các file .
  • STATIC_URL : Chỉ định URL cơ sở mà Django nên sử dụng khi tạo URL cho các file tĩnh. Ở đây, ta kết hợp URL điểm cuối và folder con file tĩnh để tạo URL cơ sở cho file tĩnh.
  • STATIC_ROOT : Chỉ định nơi thu thập các file tĩnh local trước khi sao chép chúng vào bộ nhớ đối tượng.

Để duy trì tính linh hoạt và tính di động, ta cài đặt nhiều tham số có thể cấu hình trong thời gian chạy bằng cách sử dụng các biến môi trường, giống như ta đã làm trước đây. Bao gồm các:

  • AWS_ACCESS_KEY_ID : Được đặt bởi biến môi trường STATIC_ACCESS_KEY_ID . Mã định danh khóa truy cập DigitalOcean Spaces.
  • AWS_SECRET_ACCESS_KEY : Được đặt bởi STATIC_SECRET_KEY . Khóa bí mật DigitalOcean Spaces.
  • AWS_STORAGE_BUCKET_NAME : Cài đặt bởi STATIC_BUCKET_NAME . Bộ chứa đối tượng mà Django sẽ tải nội dung lên.
  • AWS_S3_ENDPOINT_URL : Được đặt bởi STATIC_ENDPOINT_URL . URL điểm cuối được sử dụng để truy cập dịch vụ lưu trữ đối tượng. Đối với DigitalOcean Spaces, đây sẽ là một cái gì đó giống như https://nyc3.digitaloceanspaces.com , tùy thuộc vào khu vực đặt containers Spaces của bạn.

Khi bạn thực hiện xong các thay đổi đối với settings.py , hãy lưu file .

Kể từ bây giờ, khi bạn chạy manage.py collectstatic để tập hợp các file tĩnh trong dự án của bạn , Django sẽ tải chúng lên bộ nhớ đối tượng từ xa. Django hiện cũng được cấu hình để cung cấp các tài sản tĩnh từ dịch vụ lưu trữ đối tượng này.

Đến đây, nếu bạn đang sử dụng DigitalOcean , bạn có thể tùy chọn bật CDN cho Không gian của bạn , điều này sẽ tăng tốc độ phân phối các file tĩnh của dự án Django của bạn bằng cách lưu chúng vào bộ nhớ đệm qua mạng server biên được phân phối theo địa lý. Bạn cũng có thể tùy chọn cấu hình domain phụ tùy chỉnh cho Không gian của bạn . Để tìm hiểu thêm về CDN, hãy tham khảo Sử dụng CDN để tăng tốc độ phân phối nội dung tĩnh . Cấu hình CDN nằm ngoài phạm vi của hướng dẫn này, nhưng các bước rất trùng với các bước trong phần Bật CDN của Cách cài đặt ứng dụng Django có thể mở rộng với Database và không gian được quản lý DigitalOcean .

Trong bước tiếp theo, ta sẽ thực hiện một loạt các thay đổi cuối cùng đối với settings.py sẽ cho phép Django ghi log vào STDOUT và STDERR để các stream này có thể được Docker Engine chọn và kiểm tra bằng docker logs .

Bước 5 - Cấu hình ghi log

Theo mặc định, Django ghi thông tin vào kết quả tiêu chuẩn và lỗi tiêu chuẩn khi chạy server HTTP phát triển hoặc khi tùy chọn DEBUG được đặt thành True . Tuy nhiên, khi DEBUG được đặt thành False hoặc khi sử dụng một server HTTP khác, cả hai điều này đều có thể đúng trong môi trường production , Django sử dụng cơ chế ghi log khác. Thay vì ghi log mọi thứ từ INFO ưu tiên trở lên vào các stream tiêu chuẩn, nó sẽ gửi thông báo ERROR hoặc CRITICAL ưu tiên đến account email quản trị.

Điều này có ý nghĩa đối với nhiều trường hợp, nhưng trong Kubernetes và các môi trường được chứa trong containers , việc ghi lại kết quả chuẩn và lỗi chuẩn được khuyến khích. Thông điệp Logging được thu thập trong một folder tập trung vào hệ thống file của Node và có thể truy cập một cách tương tác sử dụng kubectl và docker lệnh. Tổng hợp cấp độ nút này tạo điều kiện thuận lợi cho việc thu thập log bằng cách cho phép các group vận hành chạy một quy trình trên mỗi nút để xem và chuyển tiếp log . Để tận dụng kiến trúc này, ứng dụng phải ghi log của bạn vào các bồn tiêu chuẩn này.

May mắn là đăng nhập Django sử dụng module logging có thể cấu hình cao từ thư viện chuẩn Python, vì vậy ta có thể xác định một từ điển để chuyển tới logging.config.dictConfig để xác định kết quả và định dạng mong muốn của ta . Để tìm hiểu thêm về kỹ thuật này và các kỹ thuật khác để cấu hình ghi log Django, hãy tham khảo Ghi log Django, Cách đúng đắn .

, hãy mở django-polls/mysite/settings.py trong editor .

Trước tiên, ta sẽ thêm một câu lệnh import bổ sung vào đầu file để ta có thể thao tác cấu hình ghi log :

polls-project / django-polls / mysite / settings.py
import json import os import logging.config . . .

Việc nhập logging.config cho phép ta overrides hành vi ghi log mặc định của Django bằng cách chuyển vào từ điển cấu hình ghi log mới cho hàm dictConfig .

Bây giờ, chuyển đến cuối file và paste vào khối mã cấu hình ghi log sau:

polls-project / django-polls / mysite / settings.py
. . . # Logging Configuration  # Clear prev config LOGGING_CONFIG = None  # Get loglevel from env LOGLEVEL = os.getenv('DJANGO_LOGLEVEL', 'info').upper()  logging.config.dictConfig({     'version': 1,     'disable_existing_loggers': False,     'formatters': {         'console': {             'format': '%(asctime)s %(levelname)s [%(name)s:%(lineno)s] %(module)s %(process)d %(thread)d %(message)s',         },     },     'handlers': {         'console': {             'class': 'logging.StreamHandler',             'formatter': 'console',         },     },     'loggers': {         '': {             'level': LOGLEVEL,             'handlers': ['console',],         },     }, })

Ở đây, ta đặt LOGGING_CONFIG thành None để vô hiệu hóa cấu hình ghi log mặc định do Django cung cấp. Ta đặt LOGLEVEL thành INFO theo mặc định, nhưng hãy kiểm tra biến môi trường DJANGO_LOGLEVEL để ta có thể overrides khi cần thiết.

Cuối cùng, ta sử dụng chức năng dictConfig để cài đặt một từ điển cấu hình mới bằng cách sử dụng module logging.config . Trong từ điển, ta xác định định dạng văn bản bằng cách sử dụng bộ formatters , xác định kết quả bằng cách cài đặt handlers và cấu hình thông báo nào sẽ đến từng trình xử lý bằng trình loggers .

Đây là một cấu hình khá tối thiểu cho phép bạn chỉ định mức độ nghiêm trọng của việc ghi log bằng cách sử dụng biến môi trường có tên là DJANGO_LOGLEVEL , sau đó ghi log tất cả các thông báo bằng hoặc cao hơn mức đó vào các stream tiêu chuẩn. Để có một cuộc thảo luận chuyên sâu về các cơ chế ghi log Django, hãy tham khảo Ghi log từ các tài liệu chính thức của Django.

Với cấu hình này, khi ta chứa ứng dụng, Docker sẽ hiển thị các bản ghi này thông qua lệnh docker logs . Tương tự như vậy, Kubernetes sẽ nắm bắt kết quả và hiển thị nó thông qua lệnh kubectl logs .

Điều này kết thúc các sửa đổi mã của ta đối với ứng dụng Django Polls. Trong bước tiếp theo, ta sẽ bắt đầu quá trình chứa bằng cách viết Dockerfile của ứng dụng.

Bước 6 - Viết Dockerfile ứng dụng

Trong bước này, ta sẽ xác định containers images sẽ chạy ứng dụng Django của ta và server Gunicorn WSGI sẽ phục vụ nó. Nó liên quan đến việc xây dựng containers images bằng cách xác định môi trường thời gian chạy, cài đặt ứng dụng và các phụ thuộc của nó và hoàn thành một số cấu hình cơ bản. Mặc dù có nhiều cách khả thi để đóng gói một ứng dụng trong một containers images , nhưng các phương pháp được thực hiện trong bước này sẽ tạo ra một hình ảnh ứng dụng mỏng, được sắp xếp hợp lý.

Chọn một hình ảnh root phù hợp

Quyết định quan trọng đầu tiên mà bạn sẽ phải thực hiện khi xây dựng containers images là nền tảng để xây dựng. Containers images có thể được tạo từ SCRATCH , cho biết hệ thống file trống hoặc từ containers images hiện có. Nhiều containers images cơ sở khác nhau có sẵn, mỗi hình ảnh xác định một hệ thống file và cung cấp một tập hợp các gói được cài đặt sẵn duy nhất. Hình ảnh dựa trên các bản phân phối Linux vani như Ubuntu 18.04 cung cấp một môi trường hoạt động chung, trong khi các hình ảnh chuyên biệt hơn thường bao gồm các thư viện và công cụ chung cho các ngôn ngữ lập trình cụ thể.

Khi nào có thể, bạn thường nên sử dụng hình ảnh từ một trong những repository chính thức của Docker làm cơ sở. Những hình ảnh này đã được Docker xác minh là tuân theo các phương pháp hay nhất và được cập nhật thường xuyên để sửa chữa và cải tiến bảo mật.

Vì ứng dụng của ta được xây dựng bằng Django, một hình ảnh với môi trường Python tiêu chuẩn sẽ cung cấp một nền tảng vững chắc và bao gồm nhiều công cụ mà ta cần để bắt đầu. Kho lưu trữ Docker chính thức cho Python cung cấp nhiều lựa chọn hình ảnh dựa trên Python , mỗi hình ảnh cài đặt một version Python và một số công cụ phổ biến trên đầu hệ điều hành.

Mặc dù mức độ chức năng thích hợp tùy thuộc vào trường hợp sử dụng của bạn, nhưng hình ảnh dựa trên Alpine Linux thường là một điểm nổi bật. Alpine Linux cung cấp một môi trường hoạt động mạnh mẽ nhưng tối thiểu để chạy các ứng dụng. Hệ thống file mặc định của nó rất nhỏ, nhưng bao gồm một hệ thống quản lý gói hoàn chỉnh với các repository khá rộng rãi để làm cho việc thêm chức năng trở nên đơn giản.

Lưu ý: Bạn có thể nhận thấy trong danh sách các thẻ cho hình ảnh Python có nhiều thẻ có sẵn cho mỗi hình ảnh. Các thẻ Docker có thể thay đổi và người bảo trì có thể gán lại cùng một thẻ cho một hình ảnh khác trong tương lai. Do đó, nhiều nhà bảo trì cung cấp các bộ thẻ với các mức độ cụ thể khác nhau để cho phép các trường hợp sử dụng khác nhau. Ví dụ: thẻ 3-alpine được sử dụng để trỏ đến version Python 3 mới nhất có sẵn trên version Alpine mới nhất, vì vậy nó sẽ được gán lại cho một hình ảnh khác khi version Python hoặc Alpine mới được phát hành. Để làm cho việc xây dựng hình ảnh trở nên xác định hơn, tốt nhất bạn nên sử dụng các thẻ cụ thể nhất mà bạn có thể tìm thấy cho hình ảnh bạn muốn sử dụng.

Trong hướng dẫn này, ta sẽ sử dụng hình ảnh Python được gắn thẻ là 3.7.4-alpine3.10 làm hình ảnh root cho ứng dụng Django của ta . Ta chỉ định repository và thẻ của hình ảnh root trong Dockerfile của ta bằng cách sử dụng hướng dẫn FROM .

Đầu tiên, chuyển ra khỏi folder django-polls .

  • cd ..

Sau đó, mở một file có tên Dockerfile trong trình soạn thảo mà bạn chọn. Dán vào định nghĩa hình ảnh root sau:

polls-project / Dockerfile
FROM python:3.7.4-alpine3.10

Điều này xác định điểm bắt đầu cho Docker image tùy chỉnh mà ta đang xây dựng để chạy ứng dụng của bạn .

Thêm hướng dẫn để cài đặt ứng dụng

Khi bạn đã chọn hình ảnh root , bạn có thể bắt đầu thêm hướng dẫn để cài đặt phần phụ thuộc, sao chép qua các file ứng dụng của ta và cài đặt môi trường chạy. Quá trình này thường phản ánh các bước bạn sẽ thực hiện để cài đặt một server cho ứng dụng của bạn , với một số điểm khác biệt chính để giải thích cho sự trừu tượng của containers .

Sau dòng FROM , paste vào khối mã Dockerfile sau:

polls-project / Dockerfile
. . .  ADD django-polls/requirements.txt /app/requirements.txt  RUN set -ex \     && apk add --no-cache --virtual .build-deps postgresql-dev build-base \     && python -m venv /env \     && /env/bin/pip install --upgrade pip \     && /env/bin/pip install --no-cache-dir -r /app/requirements.txt \     && runDeps="$(scanelf --needed --nobanner --recursive /env \         | awk '{ gsub(/,/, "\nso:", $2); print "so:" $2 }' \         | sort -u \         | xargs -r apk info --installed \         | sort -u)" \     && apk add --virtual rundeps $runDeps \     && apk del .build-deps  ADD django-polls /app WORKDIR /app  ENV VIRTUAL_ENV /env ENV PATH /env/bin:$PATH  EXPOSE 8000

Hãy xem qua các hướng dẫn này để giải thích một số lựa chọn ít rõ ràng hơn. Để tìm hiểu thêm về cách xây dựng Dockerfiles sẵn sàng production cho các ứng dụng Django, hãy tham khảo A Production Dockerfile dành cho Ứng dụng Django của bạn .

Đầu tiên Docker sẽ sao chép các requirements.txt file để /app/requirements.txt để phụ thuộc ứng dụng của ta có sẵn trên hệ thống file của hình ảnh. Ta sẽ sử dụng điều này để cài đặt tất cả các gói Python mà ứng dụng của ta cần để chạy. Ta sao chép file phụ thuộc như một bước riêng biệt với phần còn lại của cơ sở mã của ta để Docker có thể lưu vào cache ẩn lớp hình ảnh chứa file phụ thuộc. Bất cứ lúc nào các requirements.txt file không thay đổi giữa xây dựng, Docker sau đó có thể tái sử dụng các lớp lưu trữ thay vì xây dựng lại nó, tăng tốc quá trình này.

Tiếp theo, ta có một lệnh RUN duy nhất thực thi một danh sách dài các lệnh, mỗi lệnh được xâu chuỗi với nhau bằng cách sử dụng toán tử Linux && . Tóm lại, các lệnh sau:

  • Cài đặt các file phát triển PostgreSQL và các phụ thuộc xây dựng cơ bản bằng trình quản lý gói apk của Alpine
  • Tạo môi trường ảo
  • Cài đặt các phụ thuộc Python được liệt kê trong requirements.txt với pip
  • Biên dịch danh sách các gói cần thiết trong thời gian chạy bằng cách phân tích các yêu cầu của các gói Python đã cài đặt
  • Gỡ cài đặt mọi phụ thuộc bản dựng không cần thiết

Ta xâu chuỗi các lệnh lại với nhau thay vì thực hiện từng lệnh trong một bước RUN riêng biệt vì cách Docker xây dựng các lớp hình ảnh. Đối với mỗi lệnh ADD , COPY và RUN , Docker tạo một lớp hình ảnh mới trên đầu hệ thống file hiện có, thực thi lệnh, sau đó lưu lớp kết quả. Điều này nghĩa là nén các lệnh trong lệnh RUN sẽ dẫn đến ít lớp ảnh hơn.

Khi một mục đã được ghi vào một lớp hình ảnh, nó không thể bị xóa trong một lớp tiếp theo để giảm kích thước hình ảnh. Nếu ta cài đặt các phần phụ thuộc của bản dựng nhưng muốn xóa chúng sau khi ứng dụng được cài đặt , ta cần làm như vậy trong cùng một hướng dẫn để giảm kích thước hình ảnh. Trong lệnh RUN này, ta cài đặt các phụ thuộc xây dựng, sử dụng chúng để xây dựng các gói của ứng dụng và sau đó xóa chúng bằng cách sử dụng apk del .

Sau lệnh RUN , ta sử dụng ADD để sao chép mã ứng dụng và WORKDIR để đặt folder làm việc cho hình ảnh thành folder mã của ta .

Sau đó, ta sử dụng lệnh ENV để cài đặt hai biến môi trường sẽ có sẵn trong các containers được tạo ra từ hình ảnh của ta . Lệnh đầu tiên đặt VIRTUAL_ENV thành /env và lệnh thứ hai sửa đổi biến PATH để bao gồm folder /env/bin . Hai dòng này mô phỏng kết quả của việc tìm nguồn tập lệnh /env/bin/activate , là phương pháp kích hoạt môi trường ảo truyền thống.

Cuối cùng, ta sử dụng EXPOSE để thông báo cho Docker rằng containers sẽ lắng nghe trên cổng 8000 trong thời gian chạy.

Đến đây, Dockerfile gần hoàn thành. Ta chỉ cần xác định lệnh mặc định sẽ chạy khi ta bắt đầu các containers bằng hình ảnh.

Xác định lệnh mặc định

Lệnh mặc định của Docker image xác định điều gì sẽ xảy ra khi containers được khởi động mà không cung cấp rõ ràng lệnh để thực thi. ENTRYPOINT và CMD được dùng độc lập hoặc song song để xác định lệnh mặc định trong Dockerfile .

Khi cả ENTRYPOINT và CMD đều được xác định, ENTRYPOINT xác định file thực thi sẽ được chạy bởi containers và CMD đại diện cho danh sách đối số mặc định cho lệnh đó. User có thể overrides danh sách đối số mặc định bằng cách thêm các đối số thay thế vào dòng lệnh: docker run <image> <arguments> . Ở định dạng này, user sẽ không thể overrides lệnh ENTRYPOINT một cách dễ dàng, vì vậy lệnh ENTRYPOINT thường được đặt thành một tập lệnh sẽ cài đặt môi trường và thực hiện các hành động khác nhau dựa trên danh sách đối số mà nó nhận được.

Khi được sử dụng một mình, ENTRYPOINT cấu hình file thực thi của containers , nhưng không xác định danh sách đối số mặc định. Nếu chỉ CMD được đặt, nó sẽ được hiểu là lệnh mặc định và danh sách đối số, có thể được overrides trong thời gian chạy.

Trong hình ảnh của ta , ta muốn containers chạy ứng dụng của ta theo mặc định bằng server ứng dụng gunicorn . Danh sách đối số mà ta chuyển đến gunicorn không cần phải được cấu hình trong thời gian chạy, nhưng ta muốn khả năng dễ dàng chạy các lệnh khác nếu cần để gỡ lỗi hoặc thực hiện các việc quản lý (như thu thập tài sản tĩnh hoặc khởi tạo database ). Với những yêu cầu này, ta nên sử dụng CMD để xác định một lệnh mặc định không có ENTRYPOINT .

Lệnh CMD có thể được định nghĩa bằng bất kỳ định dạng nào sau đây:

  • CMD [" argument 1 ", " argument 2 ", . . . ," argument n "] : Định dạng danh sách đối số (được sử dụng để xác định danh sách đối số mặc định cho ENTRYPOINT )
  • CMD [" command ", " argument 1 ", " argument 2 ", . . . ," argument n "] : Các exec định dạng
  • CMD command " argument 1 " " argument 2 " . . . " argument n " : Định dạng shell

Định dạng đầu tiên chỉ liệt kê các đối số và được sử dụng cùng với một ENTRYPOINT . Hai định dạng còn lại chỉ định các lệnh và đối số của chúng, với một vài điểm khác biệt chính. Các exec định dạng, được khuyến khích, thực hiện lệnh trực tiếp, đi qua trong danh sách đối số không có chế biến vỏ. Mặt khác, định dạng shell chuyển toàn bộ danh sách sang sh -c . Điều này là cần thiết nếu, ví dụ, bạn cần thay thế giá trị của một biến môi trường trong một lệnh, nhưng thường được coi là ít dự đoán hơn.

Đối với mục đích của ta , hướng dẫn cuối cùng trong Dockerfile của ta trông giống như sau:

polls-project / Dockerfile
. . . CMD ["gunicorn", "--bind", ":8000", "--workers", "3", "mysite.wsgi:application"]

Theo mặc định, các containers sử dụng hình ảnh này sẽ thực thi gunicorn liên kết với localhost port 8000 với 3 wsgi.py và chạy chức năng application trong file wsgi.py được tìm thấy trong folder mysite . Bạn có thể tùy chọn cung cấp một lệnh trong thời gian chạy để thực hiện một quy trình khác thay vì gunicorn .

Đến đây, bạn có thể sử dụng bản docker build để xây dựng hình ảnh ứng dụng của bạn và docker run để chạy containers trên máy của bạn.

Xây dựng Docker image

Theo mặc định, lệnh docker build Dockerfile tìm kiếm Dockerfile trong folder hiện tại để tìm hướng dẫn xây dựng của nó. Nó cũng gửi “ngữ cảnh” xây dựng, cấu trúc phân cấp hệ thống file local sẽ có sẵn trong quá trình xây dựng, tới daemon Docker. Thông thường, folder hiện tại được đặt làm bối cảnh xây dựng.

Sau khi truy cập vào folder chứa Dockerfile của bạn, hãy chạy bản docker build Dockerfile , chuyển vào một hình ảnh và tên thẻ với cờ -t và sử dụng folder hiện tại làm ngữ cảnh xây dựng. Ở đây, ta đặt tên cho hình ảnh là django-polls và gắn thẻ nó với version v0 :

  • docker build -t django-polls:v0 .

Lệnh sẽ chuyển Dockerfile và folder hiện tại làm bối cảnh xây dựng cho Docker daemon. Daemon sẽ xây dựng hình ảnh của bạn bằng cách tạo một loạt các lớp hình ảnh khi nó xử lý các hướng dẫn Dockerfile .

Khi quá trình docker build hoàn tất, bạn sẽ thấy kết quả sau:

Output
Successfully built 8260b58f5713 Successfully tagged django-polls:v0

Sau khi tạo thành công hình ảnh, bạn có thể chạy containers ứng dụng bằng cách sử dụng docker run . Tuy nhiên, lệnh run rất có thể sẽ bị lỗi ở đây vì ta vẫn chưa cấu hình môi trường chạy của containers . Các biến bên ngoài như SECRET_KEY và cài đặt database từ settings.py sẽ trống hoặc được đặt thành giá trị mặc định.

Trong bước cuối cùng, ta sẽ cấu hình môi trường đang chạy của containers bằng cách sử dụng file biến môi trường. Sau đó, ta sẽ tạo schemas database , tạo và tải các file tĩnh của ứng dụng lên bộ nhớ đối tượng và cuối cùng là kiểm tra ứng dụng.

Bước 7 - Cấu hình Môi trường đang chạy và Kiểm tra Ứng dụng

Docker cung cấp một số phương pháp để cài đặt các biến môi trường bên trong containers . Vì ta phải đặt tất cả các biến mà ta đã ngoại nhập trong Bước 1, nên ta sẽ sử dụng phương thức --env-file , cho phép ta chuyển vào một file chứa danh sách các biến môi trường và giá trị của chúng.

Tạo một file có tên là env trong folder polls-project và paste vào danh sách các biến sau:

polls-project / env
DJANGO_SECRET_KEY=your_secret_key DEBUG=True DJANGO_ALLOWED_HOSTS=your_server_IP_address DATABASE_ENGINE=postgresql_psycopg2 DATABASE_NAME=polls DATABASE_USERNAME=sammy DATABASE_PASSWORD=your_database_password DATABASE_HOST=your_database_host DATABASE_PORT=your_database_port STATIC_ACCESS_KEY_ID=your_space_access_key_id STATIC_SECRET_KEY=your_space_secret_key STATIC_BUCKET_NAME=your_space_name STATIC_ENDPOINT_URL=https://nyc3.digitaloceanspaces.com DJANGO_LOGLEVEL=info

Thay thế các giá trị sau trong file này:

  • DJANGO_SECRET_KEY : Đặt giá trị này thành giá trị duy nhất, không thể đoán trước, như được nêu chi tiết trong tài liệu Django . Một phương pháp tạo khóa này được cung cấp trong Điều chỉnh cài đặt ứng dụng của hướng dẫn Ứng dụng Django có thể mở rộng .
  • DJANGO_ALLOWED_HOSTS : Đặt cái này thành địa chỉ IP của server Ubuntu của bạn. Đối với mục đích thử nghiệm, bạn cũng có thể đặt nó thành * , một ký tự đại diện sẽ trùng với tất cả các server . Đảm bảo đặt giá trị này thích hợp khi chạy Django trong môi trường production .
  • DATABASE_USERNAME : Đặt cài đặt này cho user database đã tạo ở bước trước.
  • DATABASE_PASSWORD : Đặt password này thành password user đã tạo ở bước trước.
  • DATABASE_HOST : Đặt giá trị này thành tên server database của bạn.
  • DATABASE_PORT : Đặt mục này thành cổng của database của bạn.
  • STATIC_ACCESS_KEY_ID : Đặt cái này thành khóa truy cập Không gian của bạn.
  • STATIC_SECRET_KEY : Đặt cài đặt này thành Bí mật khóa truy cập trong Không gian của bạn.
  • STATIC_BUCKET_NAME : Đặt tên này thành tên Không gian của bạn.
  • STATIC_ENDPOINT_URL : Đặt mục này thành URL điểm cuối Space thích hợp.

Khi chạy Django trong version production , hãy đảm bảo đặt DEBUG thành False và điều chỉnh mức độ log theo độ dài mong muốn của bạn.

Lưu và đóng file .

Bây giờ ta sẽ sử dụng docker run để overrides bộ CMD trong Dockerfile và tạo schemas database bằng cách sử dụng các manage.py makemigrations và manage.py makemigrations manage.py migrate :

  • docker run --env-file env django-polls:v0 sh -c "python manage.py makemigrations && python manage.py migrate"

Tại đây, ta chạy containers images django-polls:v0 , chuyển vào file biến môi trường mà ta vừa tạo và overrides lệnh Dockerfile bằng sh -c "python manage.py makemigrations && python manage.py migrate" , thao tác này sẽ tạo schemas database được xác định bởi mã ứng dụng. Sau khi chạy lệnh, bạn sẽ thấy:

Output
No changes detected Operations to perform:   Apply all migrations: admin, auth, contenttypes, polls, sessions Running migrations:   Applying contenttypes.0001_initial... OK   Applying auth.0001_initial... OK   Applying admin.0001_initial... OK   Applying admin.0002_logentry_remove_auto_add... OK   Applying admin.0003_logentry_add_action_flag_choices... OK   Applying contenttypes.0002_remove_content_type_name... OK   Applying auth.0002_alter_permission_name_max_length... OK   Applying auth.0003_alter_user_email_max_length... OK   Applying auth.0004_alter_user_username_opts... OK   Applying auth.0005_alter_user_last_login_null... OK   Applying auth.0006_require_contenttypes_0002... OK   Applying auth.0007_alter_validators_add_error_messages... OK   Applying auth.0008_alter_user_username_max_length... OK   Applying auth.0009_alter_user_last_name_max_length... OK   Applying auth.0010_alter_group_name_max_length... OK   Applying auth.0011_update_proxy_permissions... OK   Applying polls.0001_initial... OK   Applying sessions.0001_initial... OK

Điều này cho biết schemas database đã được tạo thành công.

Tiếp theo, ta sẽ chạy một version khác của containers ứng dụng và sử dụng một shell tương tác bên trong nó để tạo admin-user cho dự án Django.

  • docker run -i -t --env-file env django-polls:v0 sh

Điều này sẽ cung cấp cho bạn dấu nhắc shell bên trong containers đang chạy mà bạn có thể sử dụng để tạo user Django:

  •  python manage.py createsuperuser

Nhập tên user , địa chỉ email và password cho user của bạn và sau khi tạo user , nhấn CTRL+D để thoát khỏi containers và loại bỏ nó.

Cuối cùng, ta sẽ tạo các file tĩnh cho ứng dụng và tải chúng lên DigitalOcean bằng cách sử dụng collectstatic :

  • docker run --env-file env django-polls:v0 sh -c "python manage.py collectstatic --noinput" 
Output
 121 static files copied.

Bây giờ ta có thể chạy ứng dụng:

  • docker run --env-file env -p 80:8000 django-polls:v0 
Output
[2019-10-17 21:23:36 +0000] [1] [INFO] Starting gunicorn 19.9.0 [2019-10-17 21:23:36 +0000] [1] [INFO] Listening at: http://0.0.0.0:8000 (1) [2019-10-17 21:23:36 +0000] [1] [INFO] Using worker: sync [2019-10-17 21:23:36 +0000] [7] [INFO] Booting worker with pid: 7 [2019-10-17 21:23:36 +0000] [8] [INFO] Booting worker with pid: 8 [2019-10-17 21:23:36 +0000] [9] [INFO] Booting worker with pid: 9

Ở đây, ta chạy lệnh mặc định được xác định trong Dockerfile, gunicorn --bind :8000 --workers 3 mysite.wsgi:application và hiển thị cổng container 8000 để cổng 80 trên server Ubuntu được ánh xạ tới cổng 8000 của django-polls:v0 container.

Đến đây bạn có thể chuyển đến ứng dụng polls bằng trình duyệt web của bạn bằng lệnh http:// your_server_ip vào thanh URL. Vì không có tuyến đường nào được xác định cho / path, bạn có thể sẽ nhận được lỗi 404 Page Not Found, điều này được mong đợi.

Điều hướng đến http:// your_server_ip /polls để xem giao diện ứng dụng Polls:

Giao diện ứng dụng thăm dò ý kiến

Để xem giao diện quản trị, hãy truy cập http:// your_server_ip /admin . Bạn sẽ thấy cửa sổ xác thực quản trị ứng dụng Polls:

Trang xác thực administrator thăm dò ý kiến

Nhập tên user và password quản trị mà bạn đã tạo bằng lệnh createsuperuser .

Sau khi xác thực, bạn có thể truy cập vào giao diện quản trị của ứng dụng Polls:

Giao diện chính của administrator thăm dò

Lưu ý nội dung tĩnh cho ứng dụng admin và polls đang được phân phối trực tiếp từ bộ nhớ đối tượng. Để xác nhận điều này, hãy tham khảo Kiểm tra phân phối file tĩnh trong Spaces .

Khi bạn khám phá xong, nhấn CTRL-C trong cửa sổ dòng lệnh chạy containers Docker để hủy containers .

Kết luận

Trong hướng dẫn này, bạn đã điều chỉnh ứng dụng web Django để hoạt động hiệu quả trong môi trường root cloud , dựa trên containers . Sau đó, bạn đã viết một Dockerfile tối thiểu cho containers images , xây dựng nó local và chạy nó bằng Docker Engine. Bạn có thể thấy sự khác biệt của những thay đổi bạn đã triển khai trong nhánh thăm dò ý kiến của repository GitHub của ứng dụng Polls. Nhánh này chứa tất cả các sửa đổi được mô tả trong hướng dẫn này.

Từ đây, bạn có thể ghép nối containers Django / Gunicorn với containers Reverse Proxy Nginx để xử lý và định tuyến các yêu cầu HTTP đến và vùng chứa Certbot để lấy certificate TLS. Bạn có thể quản lý kiến trúc nhiều containers này bằng Docker Compose ; điều này sẽ được mô tả trong một hướng dẫn tiếp theo.

Lưu ý hiện tại, cài đặt này chưa sẵn sàng production vì bạn phải luôn chạy Gunicorn phía sau proxy HTTP để đệm các client chậm. Nếu không, ứng dụng web Django của bạn sẽ dễ bị tấn công từ chối dịch vụ. Ta cũng chọn 3 làm số lượng công nhân Gunicorn tùy ý trong hướng dẫn này. Trong quá trình production , bạn nên đặt số lượng công nhân và stream bằng cách sử dụng điểm chuẩn hiệu suất.

Trong kiến trúc này, ta đã đưa ra lựa chọn thiết kế để giảm tải các nội dung tĩnh xuống lưu trữ đối tượng để các containers không phải gói một version của các nội dung này và phân phát chúng bằng Nginx, điều này có thể trở nên cồng kềnh để quản lý trong môi trường cụm nhiều containers như Kubernetes . Tùy thuộc vào trường hợp sử dụng của bạn, đây có thể không phải là một thiết kế hiệu quả, vì vậy bạn nên điều chỉnh các bước trong hướng dẫn này cho phù hợp.

Cuối cùng, bây giờ bạn đã chứa đầy đủ ứng dụng Django Polls, bạn có thể đẩy hình ảnh vào register containers như Dockerhub và cung cấp nó cho bất kỳ hệ thống nào có Docker: server Ubuntu, máy ảo và cụm containers như Kubernetes.

Tags:

Các tin liên quan

Cách thiết lập Flask với MongoDB và Docker
2019-10-11
Cách cài đặt và sử dụng Docker trên Debian 10
2019-07-08
Cách sử dụng server Docker từ xa để tăng tốc quy trình làm việc của bạn
2019-06-25
Cách cài đặt WordPress với Docker Compose
2019-05-24
Cách di chuyển Docker compose workflow sang Kubernetes
2019-04-03
Cách tối ưu hóa image Docker cho sản xuất
2019-03-25
Giữ lại một ứng dụng Node.js để phát triển với Docker Compose
2019-03-05
Cách cài đặt và sử dụng Docker Compose trên CentOS 7
2019-01-23
Cách sử dụng Traefik làm reverse-proxy cho container Docker trên Debian 9
2019-01-08
Cách thiết lập registry Docker riêng trên Ubuntu 18.04
2019-01-07