Docker 101

Seminar Document
Quản trị Mạng

Nhóm 4

Nhóm 4: Docker

List of Authors
Nguyễn Huy Hùng Junior Security engineer; Student at University
of Engineering and Technology - VNU.
Email: lemaitramanh1@gmail.com
Đào Ngọc Lâm Cloud solution architect at OSAM.io; Student at
University of Engineering and Technology -
VNU.
Email: lamdn98@gmail.com
LinkedIn: www.linkedin.com/in/lamdn98
Nguyễn Thị Thúy Nga Freelancer; Student at University of Engineering
and Technology - VNU.
Email:nguyennga10198@gmail.com
Nguyễn Tân Sơn Developer at Konoha Education; Student at
University of Engineering and Technology -
VNU.
Email: tansonhn@gmail.com
LinkedIn: www.linkedin.com/in/tansonhn
Phan Văn Thắng Freelancer; Student at University of Engineering
and Technology - VNU.
Email: thang140398@gmail.com
Đinh Bá Trung Developer at SotaTek; Student at University of
Engineering and Technology - VNU.
Email: batrungdinh33@gmail.com
LinkedIn: www.linkedin.com/in/tonyvu5588

1

Nhóm 4: Docker

Abstract
Docker là nền tảng mã nguồn mở hữu ích giúp cho việc phát triển và quản
trị dễ dàng hơn. Sử dụng Docker cho phép các ứng dụng được đóng gói,
phân phối cùng các tài nguyên cần thiết trong định dạng chuẩn là
container, phù hợp mới nền tảng điện toán đám mây. Chi phí vận hành,
quản trị khi sử dụng Docker được giảm đi đáng kể so sánh với việc sử
dụng các hệ thống truyền thống.
Trong tài liệu này, chúng tôi sẽ giải thích các khái niệm cơ bản về Docker
và tầm quan trọng của Docker. Giới thiệu một số công cụ hỗ trợ quản lý
docker nổi bật, trong đó có cả các công cụ được coi là mạnh nhất hiện nay
như Docker Swarm hay Kubernetes.
Chúng tôi còn tiếp tục hoàn thiện và phát triển tài liệu này trong tương lai.
Tài liệu trình bày kèm theo (slideshow):
https://www.slideshare.net/ssuser9b325a/docker-101-144718472
Tài liệu phần demo:
https://gitlab.com/tramanh/docker101/

2

Nhóm 4: Docker

Specifications
Containerization Công nghệ container
Flask Framework Flask là một web frameworks, được xây dựng
bằng Python, cho phép bạn xây dựng các ứng
dụng web từ đơn giản tới phức tạp.
Horizontal Scale/
Scale out
Tăng/giảm theo chiều ngang bằng cách tăng số
lượng máy
Redis Hệ thống lưu trữ key-value với rất nhiều tính
năng và được sử dụng rộng rãi
Systemd Thành phần quản lý hệ thống, d tức là daemon
Upstart Một phần mềm được thiết kế với tính linh động
cao. Chúng giúp tự động khởi động các chương
trình bị tắt đi một cách liên tục
Vertical Scale/
Scale up
Tăng/giảm theo chiều dọc bằng cách tăng tài
nguyên (RAM, CPU) cho máy
Virtualization Công nghệ ảo hóa
Workload Khối lượng công việc mà một người (máy móc)
cần phải làm trong một khoảng thời gian nhất
định
Abbreviations
CD Continuous Delivery
CI Continuous Integration
CLI Command Line Interface
CNM Container Networking Model
IPAM IP Address Management
NND Network Native Driver
OS Operating System
RAID Redundant Array of Independent Disks
SAN Storage Area Network

3

Nhóm 4: Docker

Content
List of Authors 1
Abstract 2
Specifications 3
Abbreviations 3
PART I: INTRODUCTION 8
1. Virtualization 8
1.1. What is Virtualization? 8
1.2. Docker vs Hypervisor 9
1.2.1. Hypervisors 9
1.2.2. Docker 10
2. Container 10
2.1. What is Container? 10
2.2. Containers vs Package Managers 11
2.3. Containers vs Configuration Management? 12
3. Docker 13
3.1. What is Docker? 13
3.1.1. From the beginning to Docker 13
3.2. Docker’s Characteristics 15
3.3. Relevant Concepts 16
3.3.1. Docker Container 16
3.3.2. Docker images 16
3.3.3. Dockerfile 17
3.3.4. Docker Compose 17
3.3.5. Docker Hub 17
3.3.6. Docker Engine 18
3.3.7. Docker Machine 18
3.4. Why Docker? 18
3.4.1. Increased Portability 18
3.4.2. Improve Scalability 19
3.4.2.1. Vertical scaling (Scale up) 19
3.4.2.2. Horizontal scaling (Scale out) 20
3.4.3. Simple and fast deployment 20
3.4.4. Enhance Productivity 22
4

Nhóm 4: Docker

3.4.5. Improve Security 22
3.5. When Docker? 23
4.1. Development 23
4.2. Operation 24
4.2.1. Stateless Application 24
4.2.1.1. Automated workflow 24
4.2.1.2. Microservices 25
4.2.1.3. Hybrid 27
4.2.2. Stateful Application 27
PART II: CONTAINER NETWORKING 28
1. Challenge 28
2. Container Networking Model 28
2.1. Overview 28
2.2. Sandbox 29
2.3. Endpoint 30
2.4. CNM Driver Interfaces 30
2.4.1. Native network driver 31
2.4.1.1 Host 31
2.4.1.2 Bridge 31
2.4.1.3 Overlay 31
2.4.1.4 MACVLAN 32
2.4.1.5 None (Isolated) 32
2.4.2. Remote network driver 33
2.4.2.1. Docker remote network driver 33
2.4.2.2. Docker Remote IPAM Drivers 33
2.4.3. IP address management (IPAM) 34
3. Container Management Tools 34
3.1. Docker Compose 34
3.1.1. Overview 34
3.1.2. Get started 35
3.1.2.1. Setup 35
3.1.2.2. Create a Dockerfile 36
3.1.2.3. Define services in a Compose file 36
3.1.2.4. Build and run your app with Compose 37
3.1.2.5. Update the application 37
5

Nhóm 4: Docker

3.1.2.6. Experiment with some other commands 37
3.2. Docker Swarm 38
3.2.1. Overview 38
3.2.2. Swarm Architecture 38
3.3. Kubernetes 42
3.3.1. Overview 42
3.3.1.1. What is Kubernetes? 42
3.3.1.2. Who is using Kubernetes? 42
3.3.1.3. Kubernetes distributions 42
3.3.2. Kubernetes Architecture 43
3.3.2.1. Kubernetes Master (Control Plane) 43
3.3.2.2. Kubernetes Node (Minion) 43
3.3.2.3. Important concepts in Kubernetes 44
PART III: DEMO SCENARIO 48
1. From Dockerfile 48
1.1. Install & Start Docker 48
1.2. Demo 49
2. To Docker-Compose 50
2.1. Install docker-compose 50
2.2. Demo 50
2.3. Introduce Play with Docker 52
3. Docker Swarm 53
3.1. Scenario 53
3.2. Building backend 54
3.2.1. Install Gitlab 55
3.2.2. Create Docker Hub Account 56
3.2.3. Configure Gitlab Runner 56
3.2.4. Configure Docker Swarm 58
3.3. CI/CD flow 59
3.3.1. Repository's CI/CD settings 59
3.3.2. Testing 60
PART IV: APPENDIXES 64
1. Docker History 64
2. CI/CD 65
2.1. CI 65
6

Nhóm 4: Docker

2.2. CD 66
3. Who uses Docker? 66
REFERENCE 68
Paper and Documentation 68
Link and Website 69

7

Nhóm 4: Docker

PART I: INTRODUCTION
1. Virtualization
1.1. What is Virtualization?
Ngày nay áo hóa đã trở thành xu hướng chung của rất nhiều doanh nghiệp,
đặc biệt là các doanh nghiệp lớn trên thế giới. Virtualization giúp họ tiết
kiệm chi phí hiệu quả với khả năng tận dụng tối đa năng suất của các thiết
bị phần cứng. Ngoài ra vIệc áp dụng công nghệ ảo hóa máy chủ còn họ giúp
tiết kiệm không gian sử dụng, nguồn điện và giải pháp tỏa nhiệt trong trung
tâm dữ liệu, giảm thời gian thiết lập máy chủ, kiểm tra phần mềm trước khi
đưa vào hoạt động.

Hình 1.1. Hypervisor architecture.
Ảo hóa là việc chia phần cứng vật lý thành nhiều phần cứng ảo. Vì vậy, có thể
nói ảo hóa là việc chia một máy vật lý thành nhiều máy con ảo.
Công nghệ ảo hóa thực hiện ảo hóa trên máy tính, bao gồm các kỹ thuật và
quy trình thực hiện ảo hóa. Các kỹ thuật và quy trình này để tạo ra một tầng
trung gian giữa hệ thống phần cứng máy tính và phần mềm chạy trên nó. Ý
8

Nhóm 4: Docker

tưởng ban đầu của công nghệ ảo hóa là từ một máy vật lý đơn lẻ có thể tạo
thành nhiều máy ảo độc lập. Nó cho phép tạo nhiều máy ảo trên một máy
chủ vật lý, mỗi một máy ảo cũng được cấp phát tài nguyên phần cứng như
máy thật gồm có RAM, CPU, Card mạng, ổ cứng, các tài nguyên khác và hệ
điều hành riêng. Khi chạy ứng dụng, người sử dụng chỉ chú ý tới khái niệm
logic về tài nguyên máy tính hơn là khái niệm vật lí về tài nguyên máy tính.
Hệ thống máy chủ được thiết kế để chạy một hệ điều hành và một ứng
dụng sẽ không khai thác triệt để hiệu năng của hầu hết các máy chủ rất lớn.
Vì thế sự ra đời của ảo hóa cho phép ta vận hành nhiều máy chủ ảo trên
cùng một máy chủ vật lý, dùng chung các tài nguyên của một máy chủ vật
lý qua nhiều môi trường khác nhau. Các máy chủ ảo khác nhau có thể vận
hành nhiều hệ điều hành và ứng dụng khác nhau trên cùng một máy chủ
vật lý.
Các công nghệ hỗ trợ ảo hóa bao gồm: cân bằng tải, cân bằng tải mạng, cân
bằng clustering, công nghệ RAID, công nghệ lưu trữ mạng SAN. Các kiểu ảo
hóa cơ bản bao gồm: ảo hóa hệ thống mạng, ảo hóa hệ thống lưu trữ, ảo hóa
ứng dụng, ảo hóa hệ thống máy chủ.
Trong các công nghệ ảo hóa ứng dụng, Docker là một dự án mã nguồn mở
phát hành theo giấy phép Apache và được đánh giá là tương lai của ảo hoá
ứng dụng.
Docker đưa ra một giải pháp mới cho vấn đề ảo hóa, thay vì tạo ra các máy
ảo con chạy độc lập kiểu hypervisors (tạo phần cứng ảo và cài đặt hệ điều
hành lên đó), các ứng dụng sẽ được đóng gói lại thành các Container riêng
lẻ. Các Container này chạy chung trên nhân hệ điều hành qua LXC (Linux
Containers), chia sẻ chung tài nguyên của máy mẹ, do đó, hoạt động nhẹ và
nhanh hơn các máy ảo dạng hypervisors.
1.2. Docker vs Hypervisor
1.2.1. Hypervisors
Hypervisor – Phần mềm giám sát máy ảo: Là một chương trình phần mềm
quản lý một hoặc nhiều máy ảo (VM). Nó được sử dụng để tạo, startup, dừng
và reset lại các máy ảo. Các hypervisor cho phép mỗi VM hoặc “guest” truy
cập vào lớp tài nguyên phần cứng vật lý bên dưới, chẳng hạn như CPU, RAM
và lưu trữ. Nó cũng có thể giới hạn số lượng tài nguyên hệ thống mà mỗi
máy ảo có thể sử dụng để đảm bảo cho nhiều máy ảo cùng sử dụng đồng
thời trên một hệ thống.
Đối với Virtual Machine (Hypervisors) thì cần thêm một Guest OS cho nên sẽ
tốn tài nguyên hơn và làm chậm máy thật khi sử dụng. Thời gian khởi động
9

Nhóm 4: Docker

trung bình là 20s có thể lên đến hàng phút, thay đổi phụ thuộc vào tốc độ
của ổ đĩa.

Hình 1.2. Hypervisor-based vs Container.
1.2.2. Docker
Khác với Hypervisor, Docker dùng chung kernel, chạy độc lập trên Host
Operating System và có thể chạy trên bất kỳ hệ điều hành nào cũng như
cloud. Khởi động và làm cho ứng dụng sẵn sàng chạy trong 500ms, mang lại
tính khả thi cao cho những dự án cần sự mở rộng nhanh.
Hypervisor Docker
Ảo hóa phần cứng trở lên
Nặng, start (boot) chậm
Real-time provisioning & scalability
Limited performance
Fully isolated
Sử dụng resources lãng phí
Ảo hóa OS trở lên
Nhẹ, start nhanh
Slow provisioning
Native performance
Process-level isolation
Sử dụng resources hiệu quả hơn
2. Container
2.1. What is Container?
Các phần mềm, chương trình sẽ được Container Engine ( là một công cụ ảo
hóa tinh gọn được cài đặt trên host OS) đóng gói thành các container.
Vậy thì Container là gì? Nó là một giải pháp để chuyển giao phần mềm một
cách đáng tin cậy giữa các môi trường máy tính khác nhau bằng cách tạo ra
một môi trường chứa mọi thứ mà phần mềm cần để có thể chạy được mà
10

Nhóm 4: Docker

không bị các yếu tố liên quan đến môi trường hệ thống làm ảnh hưởng tới
cũng như không làm ảnh hưởng tới các phần còn lại của hệ thống.
Một số đặc điểm của Container:
● Containers chia sẻ kernel của host (dùng chung host OS).
● Containers sử dụng kernel để nhóm các tiến trình khi kiểm soát tài
nguyên.
● Containers hoàn toàn cô lập thông qua các namespaces giúp tránh
ảnh hưởng đến các môi trường khác.
● Containers nhanh, nhẹ như Virtual Machines nhưng không phải là
Virtual Machines!
Các thành phần của một Container ecosystem bao gồm:
● Runtime
● Image distribution
● Tooling
2.2. Containers vs Package Managers
VÌ sao Container khác với package management?
VIệc đóng gói vào một image cũng gần giống như RPM nhưng lại khác với
distributions - software của Linux (thường ít khi được đóng gói chính xác).
Sự cải tiến của Docker nằm ở chỗ nó quản lý các package dễ dàng hơn.
Thông thường thì Package managers hay gặp lỗi do việc không đồng nhất
các phiên bản khi chia sẻ thư viện dẫn tới các sự cố liên quan. Tuy nhiên việc
đóng gói các thư viện được chia sẻ ấy vào một image sẽ giúp giải quyết vấn
đề trên.
Ở đây, chúng ta không ảo hoá cả phần cứng và hệ điều hành "như thật" nữa
mà chỉ ảo hóa môi trường. Các service trong Container vẫn chạy chung hệ
điều hành chủ ở phía dưới, chung Kernel nhưng môi trường chạy của các
service thì luôn được đảm bảo hoàn toàn độc lập với nhau như sơ đồ biểu
diễn dưới đây:
11

Nhóm 4: Docker

Hình 1.3. Container architecture.
● Tham khảo: Shipping Manifests, Bill of Lading and Docker Metadata and Containers -
Video. [2.1]
2.3. Containers vs Configuration Management?
Những tiện ích của Configuration Management (Quản lý Cấu hình) cung cấp
khả năng lưu trữ hạ tầng như code. Những công cụ CM phổ biến bao gồm:
● Puppet (Ruby)
● Chef (Ruby)
● Ansible (Python)
● SALT (Python)
● Terraform (Golang)
Một số công cụ trên thường tạo ra môi trường không giống một package
được phân phát độc lập và chạy một cách chính xác trên mọi môi trường (vì
môi trường có thể khác nhau khi phân phát trên Linux [Ubuntu/redhat/..],
scale [local laptop / server cluster/ …], …). Tuy nhiên ví dụ như trong Docker
chúng ta vẫn có thể tận dụng đến công cụ trên để khởi động Docker
infrastructure và để cho lớp Container Runtime hỗ trợ tầng ứng dụng khi nó
sẵn sàng.
12

Nhóm 4: Docker

3. Docker
3.1. What is Docker?
Docker là một open platform cung cấp cho người sử dụng những công cụ và
service để người sử dụng có thể đóng gói và chạy chương trình của mình
trên các môi trường khác nhau một cách nhanh nhất. Ban đầu Docker được
viết bằng Python sau đó chuyển sang Go-lang. Docker hỗ trợ nhiều nền tảng
hệ điều hành khác nhau bao gồm Linux, Windows và cả Mac. Ngoài ra,
Docker còn hỗ trợ nhiều dịch vụ điện toán đám mây nổi tiếng như Microsoft
Azure hay Amazon Web Services.
3.1.1. From the beginning to Docker
Ngày xưa, mô hình máy chủ thường là 1 máy chủ vật lý, 1 hệ điều hành (OS), 1
application. Tuy nhiên khi ứng dụng phát triển lên, mô hình này nảy sinh ra
nhiều vấn đề như lãng phí tài nguyên (mặc dù cấu hình máy khỏe, ổ cứng
dung lượng lớn, nhưng hệ thống lại không tận dụng được hết lợi thế này).
Vấn đề tiếp theo là khó khăn trong việc mở rộng hệ thống (muốn mở rộng
phải thuê thêm server, cấu hình, cân bằng tải…).

Hình 1.4.
Lúc này, công nghệ ảo hóa (virtualization) ra đời.

Hình 1.5.
13

Nhóm 4: Docker

Với công nghệ ảo hóa, trên cùng 1 máy chủ vật lý, có thể tạo ra nhiều OS, tức
là sẽ chạy được nhiều application. Vì vậy tài nguyên của máy được tận dụng
tốt hơn. Tuy nhiên, việc ảo hóa này cũng lại nảy sinh vấn đề mới:
● Ngốn tài nguyên. Bởi vì khi chạy 1 máy ảo, nó sẽ luôn chiếm 1 phần tài
nguyên cố định. (Giả sử như máy chủ có 512GB SSD, 16GB RAM, nếu
tạo ra 4 máy ảo Linux, mỗi máy cấp 64GB SSD và 2GB RAM, như vậy,
sẽ mất 256GB SSD để chứa 4 máy ảo, và khi chạy cùng 4 máy ảo lên
cùng lúc, chúng sẽ chiếm 8GB RAM. Mặc dù nếu chỉ chạy lên và
không sử dụng thì nó vẫn chiếm từng đó).
● Tốn thời gian thực thi. Thời gian khởi động, shutdown của các máy ảo
sẽ lâu, thường là hàng phút.
● Cồng kềnh. Việc phải chịu tải cho cả 1 nhóm máy ảo như vậy thì server
không thế chạy hết hiệu suất được.
Bước tiến hóa tiếp theo, người ta phát minh ra Containerization.

Hình 1.6.
Với công nghệ này, trên một máy chủ ta sẽ sinh ra được nhiều máy con
giống với ảo hóa. Tuy nhiên điều đặc biệt là các máy con (Guess OS) này đều
dùng chung phần nhân của máy mẹ (host OS) và chia sẻ với nhau tài nguyên
của máy mẹ (RAM chẳng hạn). Như vậy việc tận dụng tài nguyên sẽ được tối
ưu hơn.
Ngoài ra, việc sử dụng hệ thống file cắt lớp (layer file system) sẽ khiến việc tối
ưu tài nguyên đạt hiệu quả cao hơn. Cụ thể, mỗi máy con (container) mới sẽ
được xây dựng dựa trên 1 file ảnh (image) dạng chỉ đọc (read-only). Trong
mỗi máy con sẽ có thêm 1 lớp có thể ghi được (writable-layer), các thay đổi
trong máy con sẽ được ghi lên đây. Như vậy, từ 1 image ban đầu, ta có thể tạo
nhiều máy con mà chỉ tốn rất ít dung lượng ổ đĩa.
14

Nhóm 4: Docker

Điểm khác biệt chính là các containers sử dụng chung kernel với Host OS
nên các thao tác bật, tắt rất nhẹ nhàng, nhanh chóng. Vì thế Docker nhanh,
nhẹ và có thể chia sẻ dễ dàng qua DockerHub.
3.2. Docker’s Characteristics
Docker hiện tại là ecosystem duy nhất cung cấp đầy đủ các package:
● Quản lý image (Image management)
● Độc lập tài nguyên (Resource Isolation)
● Độc lập hệ thống tập tin (File System Isolation)
● Độc lập mạng (Network Isolation)
● Quản lý các chỉnh sửa (Change Management)
● Chia sẻ (Sharing)
● Quản lý tiến trình (Process Management)
● Khám phá dịch vụ (Service Discovery) (DNS since 1.10)
Docker phát huy những giá trị tiềm năng mới bằng cách cho cho phép
chúng ta tự do xây dựng, quản lý và bảo mật các ứng dụng quan trọng trong
công việc mà không phải lo những hạn chế về công nghệ.
Đồng nhất
______________________________________________
● Khi nhiều người cùng phát triển trong cùng một dự án sẽ không bị sự
sai khác về mặt môi trường.
Đóng gói
______________________________________________
● Có thể ẩn môi trường bao gồm cả app vào trong một gói được gọi là
container.
● Có thể test được các container.
● Việc bỏ hay tạo lại container rất dễ dàng.
Linh động (nhất quán)
______________________________________________
● Có thể test container được dùng để phát triển bằng CI.
● Có thể deploy container đã được test bằng CI lên server.
● Có thể scale container đã được deploy.
Tốn ít tài nguyên
______________________________________________
● Do các kernel OS có thể chia sẻ tài nguyên cho nhau, nên bớt đi được
khá nhiều tài nguyên không cần thiết.
15

Nhóm 4: Docker

Tóm lại, Docker cung cấp cho người dùng một nền tảng cơ bản để giúp
người dùng có thể dễ dàng xây dựng được các hệ thống phân tán trên nền
tảng container. Song song với việc đó, Docker cũng cung cấp cho chúng ta
một hệ sinh thái hoàn chỉnh từ việc quản lý Docker Image cho cả tới việc
quản lý runtime của các container trên các hệ thống máy chủ phức tạp.
Docker đã được chấp nhận và sử dụng ngày càng rộng rãi. Nhiều công ty tập
đoàn lớn (đặc biệt là Google) đã triển khai trên hầu hết các dịch vụ của họ. Vì
thế sẽ không có gì bất ngờ khi cho rằng Container sẽ là tương lai của công
nghệ "ảo hoá", dần thay thế giải pháp ảo hoá truyền thống.
3.3. Relevant Concepts
3.3.1. Docker Container
Mỗi một Docker Container được tạo ra từ một Docker image. Các thao tác
với một container: create, start, stop, move or delete container dựa trên
Docker API hoặc Docker CLI.
Chúng ta có thể tự tạo một Container từ các template có sẵn, cài đặt môi
trường, service, sau đó lưu trạng thái Container lại như là một "image" và
triển khai image này đến bất kỳ chỗ nào chúng ta mong muốn. Docker cho
phép chúng ta có thể lưu Container lại trên Cloud cực kỳ thuận tiện.
Là ảo hoá nhưng Container lại rất nhẹ. Hệ điều hành chủ quản lý các
Container bằng Systemd hoặc Upstart. Do vậy, các Container ở đây như là
một process của hệ thống. Chỉ mất vài giây để start, stop hay restart một
Container, và khi các container ở trạng thái Idle (chờ) chúng gần như không
tiêu tốn tài nguyên CPU. Với một máy tính cấu hình thông thường, nếu chạy
máy ảo truyền thống chúng ta chỉ chạy được khoảng vài cái là cùng. Tuy
nhiên nếu chạy bằng Container chúng ta có thể chạy vài chục thậm chí đến
cả vài trăm cái.
3.3.2. Docker images
Là một “read-only template” để tạo ra Docker container. Nó giống như tập
hợp của các thư viện hệ thống, công cụ, các file và những phụ thuộc khác,
được đóng gói lại vào một Docker image như một môi trường phát triển. Ví
dụ, một image chứa hệ điều hành Ubuntu đã cài đặt sẵn Apache và ứng
dụng web.
● Từ các image này, bạn sẽ dùng nó để tạo ra các container nhờ Docker
engine, các image là dạng ﬁle-chỉ-đọc (read only ﬁle).
● Ta có thể tự tạo image cho riêng mình dựa trên chỉ dẫn của
Dockerfile.
● Một image có thể được tạo từ nhiều image khác.
16

Nhóm 4: Docker

3.3.3. Dockerfile
Là file chứa các đặc tả về môi trường thực thi phần mềm, hay nói cách khác
đó là một file chứa tập hợp các lệnh để Docker có thể đọc và thực hiện để
đóng gói một image theo yêu cầu người dùng.

Hình 1.7.
3.3.4. Docker Compose
Compose là công cụ giúp định nghĩa và khởi chạy multi-container Docker
applications. Trong Compose, chúng ta sử dụng Compose file để cấu hình
applications’ services. Chỉ với một câu lệnh, ta có thể dễ dàng tạo và khởi
động toàn bộ các services phục vụ cho việc chạy ứng dụng.
Việc sử dụng Docker Compose được tóm lược trong 3 bước cơ bản sau:
● Khai báo môi trường ứng dụng với Dockerﬁle.
● Khai báo các services cần thiết để chạy ứng dụng trong
docker-compose.yml.
● Run docker-compose up và Compose sẽ khởi động và chạy ứng dụng.
3.3.5. Docker Hub
Là dịch vụ cloud để chia sẻ ứng dụng và tự động hóa chuỗi các công việc
liên tục, có thể thao tác pull/push với các images. Docker Hub cũng giống
như Github cho phép bạn download các Docker Images khác đã được build
từ cộng đồng (public) hoặc nhà phát hành ứng dụng. Bạn cũng có thể đăng
ký tài khoản Docker Hub cá nhân và upload file Docker Image đã build của
bạn lên Docker Hub để lưu trữ (giống như quản lý image như upload code
lên Github repository)
Docker Hub còn có khả năng giúp bạn kết nối tới code repository, build
image của bạn và chạy thử nghiệm image đó, lưu trữ các push image,…
Docker Hub còn có thể quản lý tập trung Container Image, phân phối, quản
lý sự thay đổi Image, workﬂow tự động hoá thông qua các pipeline CI/CD, …
17

Nhóm 4: Docker

3.3.6. Docker Engine
Là ứng dụng client-server với các thành phần chính:
● Một máy chủ là một loại chương trình dài, chạy được gọi là quá trình
daemon (lệnh docker).
● API REST chỉ định các giao diện mà các chương trình có thể sử dụng
để nói chuyện với daemon và hướng dẫn nó làm gì.
● Giao diện dòng lệnh CLI ( docker command line )
● CLI sử dụng API của Docker REST để điều khiển hoặc tương tác với
daemon Docker thông qua kịch bản hoặc các lệnh CLI trực tiếp. Nhiều
ứng dụng Docker khác sử dụng API cơ bản và CLI.

Hình 1.8.
3.3.7. Docker Machine
Là một provisioning tool để tiếp cận Docker. Machine tạo Docker Engine
trên máy của bạn hoặc trên bất cứ dịch vụ cloud phổ biến nào (như AWS,
Azure, Google Cloud, Softlayer) hoặc trên hệ thống data center (như VMware,
OpenStack). Docker Machine sẽ tạo các máy ảo và cài Docker Engine lên
chúng và cuối cùng nó sẽ cấu hình Docker Client để giao tiếp với Docker
Engine một cách bảo mật.
3.4. Why Docker?
3.4.1. Increased Portability
Một trong những lợi ích chính trong việc sử dụng Docker và công nghệ
Container là tính di động của chúng.
Tính di động ở đây được hiểu theo nghĩa: Docker có thể chạy trên nhiều môi
trường khác nhau: linux, windows hay mac OS.
18

Nhóm 4: Docker

Do mỗi container là một môi trường riêng biệt và độc lập với hệ điều hành
trên host hay server, chỉ cần cài đặt trên nó Docker Engine, mọi máy đều có
thể pull về và chạy các container được build từ một image duy nhất.
Bạn sẽ không cần quá bận tâm đến hệ điều hành chạy trên server nữa, dù là
Windows hay các phiên bản Linux. Thay vào đó, sẽ có nhiều thời gian để
chuẩn bị cho các phần khác, phần nào giúp tăng hiệu quả công việc.
Để dễ hiểu hơn, hãy tưởng tượng đến các container trong thực tế. Các
container có thể được trở bởi bất kỳ con tàu nào, bởi bất kỳ nhà cung cấp vận
tải nào, hoặc thậm chí được chở bằng một chiếc xe tải. Dẫu vậy, hàng hóa
được chứa bên trong container đó không đổi và hoàn toàn độc lập với
phương tiện trở nó.
Hướng dẫn cài đặt Docker:
● Linux: https://runnable.com/docker/install-docker-on-linux.
● Windows: https://docs.docker.com/docker-for-windows/install.
3.4.2. Improve Scalability
Khi nhắc đến khả năng scale, chúng ta đề cập tới cả khả năng tăng và giảm
nguồn lực (compute resource) một cách hợp lý, linh hoạt và có kiểm soát.
Cụ thể hơn, các nguồn lực được nhắc đến ở đây chính là các container.
Chúng cần phải được sử dụng một cách hợp lý sao cho vừa đảm bảo phục
vụ người dùng, vừa tối ưu việc sử dụng tài nguyên từ hệ thống.
Với công nghệ Containerization, Các container có thể scale theo 2 cách:
● Vertical (hay còn gọi là scale up hay scale theo chiều dọc).
● Horizontal (hay còn gọi là scale out hay scale theo chiều ngang).
3.4.2.1. Vertical scaling (Scale up)
Vertical scale hay scale up là kĩ thuật tăng trực tiếp sức mạnh tính toán
(compute) cho từng máy (machine). Ví dụ điển hình và việc tăng dung lượng
RAM, tăng CPU,... cho máy chủ.

Hình 1.9. Vertical scaling.
19

Nhóm 4: Docker

Tuy nhiên, với kỹ thuật này, luôn có giới hạn nhất định về phần cứng. Tuy có
thể mua thêm RAM, thay CPU tốt hơn, nhưng đến một giới hạn nào đó, RAM
sẽ đạt đến giới hạn tối đa, và CPU hay các tài nguyên khác cũng vậy. Hơn
nữa, kĩ thuật này có thể khiến người quản lý thao tác thủ công và khó để
đánh giá được khi nào cần tăng/giảm với các hệ thống có lượng người dùng
không ổn định trong thời gian ngắn. Chính vì vậy mà Scale up không thể
đảm bảo vận hành cho một hệ thống lớn được.
3.4.2.2. Horizontal scaling (Scale out)
Để scale vượt ra khỏi giới hạn vật lý, người ta sử dụng kỹ thuật Horizontal
scale.
Đây là kỹ thuật cho phép tăng sức mạnh tính toán (compute) bằng các tăng
thêm các container hoặc tăng thêm nhiều máy chủ chạy song song. Nếu
lượng người dùng tăng đột biến hoặc không ổn định trong thời gian ngắn,
hệ thống sẵn sàng tự động chạy thêm container và máy chủ phục vụ (nếu
cần thiết) để đáp ứng nhu cầu xử lý nhanh nhất có thể.

Hình 1.10. Horizontal scaling.
Ưu điểm của kỹ thuật này là hệ thống có thể mở rộng vô hạn, có thể tự động
triển khai nhanh chóng. Tuy nhiên, để áp dụng được mô hình horizontal
scale, ứng dụng hệ thống cần phải là ứng dụng stateless do mỗi máy chủ
phục vụ dù có cùng chức năng nhưng vẫn độc lập với nhau và không phân
biệt giữa các người dùng với nhau.
● Xem thêm: PART I/ When Docker/ Operation.
3.4.3. Simple and fast deployment
Với Docker, có thể khởi chạy hoặc xóa một hay nhiều container chỉ với một
vài câu lệnh run đơn giản.
Với một container container, chỉ cần chạy một lệnh:
1. docker run [OPTIONS] IMAGE [COMMAND] [ARG...]
20

Nhóm 4: Docker

Ví dụ: để chạy một container từ image có tên hello-world và lắng nghe ở port
80:
1. docker run -t -i -p 80:80 hello-world
● Xem thêm: Docker run. [2.2]
Với hệ thống nhiều container, có thể dựa trên phương thức deploy của
Docker management tools để triển khai nhanh chóng một số lượng
container được định nghĩa trước.
Lấy ví dụ với Kubernetes, chỉ cần xác định các thông số trong file định dạng
.yaml, sau đó chạy lệnh apply vào hệ thống. Hệ thống sẽ tự động phát hiện
thay đổi và tạo mới hoặc cập nhật dựa trên tên file và thông số chứa trong
nó.

Hình 1.11.
Trên đây là file deploy có tên nginx-deployment .yaml. Trong đó có chứa các
thông số cụ thể giúp cho việc deploy được dễ dàng. Khi khởi chạy, người
dùng chỉ cần chạy câu lệnh duy nhất, sau đó hệ thống sẽ apply và triển khai:
1. kubectl apply -f nginx-deployment.yaml
Trong trường hợp update hệ thống, chỉ cần chỉnh sửa thông số trong file cài
đặt được lưu trong máy và chạy lại câu lệnh trên, hoặc có thể truy cập và sửa
trực tiếp trên hệ thống của kubernetes bằng câu lệnh:
1. kubectl edit deployment.v1.apps/nginx-deployment
Ngoài ra, còn một số câu lệnh khác cho phép trực tiếp sửa thông số deploy.
● Xem thêm: APPENDIXES/kubernetes.
21

Nhóm 4: Docker

3.4.4. Enhance Productivity
Khi triển khai một ứng dụng, có 3 môi trường triển khai riêng biệt, đó là môi
trường Dev/Test, Staging và Production. Để đảm bảo được ứng dụng chạy
chính xác, cần phải cài đặt cả 3 môi trường trên sao cho giống nhau nhất có
thể. Tuy nhiên, xây dựng và triển khai một ứng dụng luôn có 2 phần:
Development và Operation. Phần development là phần thiết kế, xây dựng
ứng dụng và kiểm thử, đa số được chạy ngay trên máy của các developer.
Trong khi đó, ứng dụng hoàn thiện cần được triển khai tới giai đoạn
operation hay deploy lên server.
Việc cài đặt môi trường cho một ứng dụng trên server sẽ mất thêm thời gian
và có thể gặp nhiều khó khăn do việc tổng hợp những thư viện cần thiết (do
mỗi developer không làm cả ứng dụng mà chia ra nhiều phần, mỗi người
làm một số phần, mỗi phần lại cần các phiên bản thư viện tương ứng).
Với công nghệ docker, chỉ cần dùng một image duy nhất cho cả hai quá
trình development và operation. Khi cần sử dụng thêm thư viện, chỉ cần cài
thêm thư viện đó vào image mới dựa trên image đã có và push lên
repository. Như vậy, vấn đề về cài đặt môi trường đã được giải quyết.
Hơn nữa, khi sử dụng Docker, có thể dựng hệ thống CI/CD (Continuous
Integration/ Continuous Delivery) giúp cho việc deploy nhanh hơn và hoàn
toàn tự động. Bản chất của hệ thống này là sử dụng một container build
toàn bộ source code của ứng dụng và đóng gói nó, sau đó deploy lên server.
Trong quá trình deploy, nếu có lỗi sẽ thực hiện bước rollback về phiên bản
cũ. Thông thường, một hệ thống CI/CD triển khai một ứng dụng lên server
trong chưa đầy 2 phút tùy theo độ lớn của ứng dụng.
● Xem thêm CI, CD và... DevOps.[2.3]
● Xem thêm APPENDIXES/CICD.
3.4.5. Improve Security
Khi sử dụng Docker, mỗi nhóm container chỉ thực hiện một công việc duy
nhất, vì vậy hệ thống được phân lớp rất rõ ràng. Mỗi một lớp kèm theo nó là
các cài đặt nhằm tăng tính bảo mật.
22

Nhóm 4: Docker

Hình 1.12. Mô ta một ứng dụng multi-tier application.
Giả sử, với một hệ thống có cấu trúc 4 tầng như hình trên, với các nhóm
container với chức năng rõ ràng, để tăng tính bảo mật, người ta thường cài
đặt các tầng phía sau chỉ lắng nghe và nhận request từ tầng ngay trước nó.
Ví dụ, với tầng Database, tầng này không được cài đặt public IP và không thể
kết nối ra ngoài internet. Mọi truy cập (query) đến database chỉ được thực
hiện qua kết nối internal. Như vậy, muốn xem được dữ liệu, không còn cách
nào khác, người dùng (user) chỉ có thể đi qua từng lớp mà thôi.
Hơn nữa, việc có thể tấn công từ tầng ảo hóa xuống tầng vật lý gây khó khăn
hơn nhiều so với việc tấn công trực tiếp vào máy chủ vật lý.
● Xem thêm Docker security. [2.4]
3.5. When Docker?
4.1. Development
Dưới đây là một vài lý do tại sao chúng ta nên dùng Docker cho việc
Development:
● Môi trường Dev nhất quán cho cả team. Tất cả đều sử dụng cùng một
hệ điều hành, cùng thư viện hệ thống, cùng ngôn ngữ để dev, bất kể
máy chủ đang sử dụng hệ điều hành nào(ngay cả Windows).
● Môi trường Dev giống hệt như môi trường sản xuất. Có nghĩa là bạn
có thể triển khai và nó chắc chắn sẽ hoạt động.
● Nếu bạn gặp khó khăn trong việc xây dựng một cái gì đó, hãy xây
dựng nó bên trong Docker. Điều này chủ yếu áp dụng cho các nhà
phát triển sử dụng MacOS và Windows.
● Bạn chỉ cần Docker để phát triển. Bạn không cần phải cài đặt một loạt
các môi trường trên máy của mình. Ví dụ: Bạn muốn chạy tập lệnh
23

Nhóm 4: Docker

Ruby nhưng chưa cài đặt Ruby? Chạy nó trong một “Ruby Docker
image”.
● Có thể sử dụng nhiều phiên bản ngôn ngữ mà không cần phải cập
nhật hay tải một phiên bản khác (python, ruby, java, nodeJs, ...). Ví dụ:
Bạn muốn chạy chương trình Python của mình trong Python 3,
nhưng bạn chỉ có Python 2? Hãy chạy nó bằng cách sử dụng “Python
3 image”. Bạn muốn biên dịch chương trình Java của bạn với Java 1.6
thay vì 1.7 đã được cài đặt trên máy của bạn? Biên dịch nó trong một
“Docker Java 1.6 image”.
● Triển khai dễ dàng. Nếu nó chạy trong container của bạn như thế nào,
thì trên máy chủ của bạn sẽ y như vậy. Chỉ cần đóng gói code của bạn
và triển khai nó trên một máy chủ với cùng image đó hoặc tạo một
Docker image mới với code của bạn trong đó và chạy image mới đó.
● Vẫn có thể sử dụng trình soạn thảo hoặc IDE yêu thích của bạn như
bình thường. Không cần chạy một máy ảo trong VirtualBox và SSH
vào đó rồi phát triển từ shell để mà có thể build / run trên máy Linux.
Để có thể dùng Docker cho việc Dev, trước tiên cần phải cài Docker và
docker-compose trong máy. Sau đó là kiến thức về docker-compose, cách
viết một file .yml để có thể setup thành công các loại database, cache, …
dùng chung cho việc phát triển nhiều dự án.
(Trong môi trường Linux)
Sau khi có một ﬁle .yml hoàn chỉnh nhớ hãy chạy lệnh docker-compose-up.
4.2. Operation
4.2.1. Stateless Application
Stateless Application là các ứng dụng không lưu lại thông tin về session trên
server, hay trong trường hợp này là container. Điều này có nghĩa là: sau khi
client gửi dữ liệu lên server, server thực thi xong, trả kết quả thì “quan hệ”
giữa client và server bị “cắt đứt” – server không lưu bất cứ dữ liệu gì của
client.
4.2.1.1. Automated workflow
Automated workflow là một quy trình làm việc tự động, mỗi công đoạn được
đảm nhiệm bởi một bộ phần khác, mỗi bộ phận nhận vào một input và trả
lại kết quả là output, output của quá trình trước là input của quá trình sau.
24

Nhóm 4: Docker

Hình 1.13. Một ví dụ về automated workﬂow.
Trên đây là một ví dụ về workﬂow của một hệ thống bán hàng online.
● Bắt đầu bằng một order từ khách hàng.
● Ngay sau đó, Order Verifiers sẽ thực hiện bước xác thực đơn hàng và
chuyển đơn hàng đến bước tiếp thanh toán.
● Tại bước thanh toán, bộ phận Credit Card Processors tiếp nhận thông
tin về đơn hàng và thực hiện xác nhận thông tin thanh toán. Kết thúc
bước này, đơn hàng được chuyển sang bộ phận giao hàng.
● Bộ phận giao hàng nhận đơn hàng, giao tới địa chỉ order và kết thúc
bằng việc bấm nút "đã giao hàng".
● Sau khi đơn hàng được xác nhận, hệ thống lưu trữ thêm đơn hàng đó
vào kho dữ liệu (database) và kết thúc đơn hàng.
Với Docker, có thể dựng các hệ thống tương tự trên, với các bước như order
verify, credit card process và database record, ... Một trong những hệ thống
automated workflow khá hot hiện tại là hệ thống CI/CD giúp thực hiện tự
động các bước build và deploy ứng dụng ngay sau khi các developers đẩy
source code lên repository.
● Xem thêm APPENDIXES/CICD.
4.2.1.2. Microservices
Trước đây khi sử dụng kiến trúc ứng dụng một khối (monolithic application)
một ứng dụng được xây dựng với đầy đủ các khía cạnh khác nhau. Tuy rằng
các module của ứng dụng có cấu trúc hợp lý, tuy nhiên sau một thời gian, số
lượng người dùng tăng lên, yêu cầu về tính năng mới, thuật toán mới,... và
kết quả là ứng dụng ngày càng đồ sộ, việc nâng cấp cũng ngày một khó hơn
do sự liên quan đến thư viện sử dụng chung và cấu trúc có liên quan đến
nhau của hàng ngàn dòng code.
25

Nhóm 4: Docker

Nhiều tập đoàn công nghệ lớn đã chọn cách xử lý vấn đề bằng cách sử dụng
kiến trúc microservices, với ý tưởng chia nhỏ ứng dụng thành nhiều ứng
dụng liên kết với nhau.

Hình 1.14. Mô hình microservice của một ứng dụng gọi xe.
Ưu điểm của kiến trúc xây dựng theo kiểu microservices bao gồm:
● Giảm thiểu sự phức tạp của một hệ thống lớn.
● Chia nhỏ các dịch vụ giúp dễ dàng quản lý, nâng cấp, và thoải mái
chọn công nghệ hơn.
● Microservice thúc đẩy tách rạch ròi các khối chức năng (loose
coupling - high cohesion), điều rất khó thực hiện với ứng dụng 1 khối.
Tuy nhiên, không thể hoàn hảo 100%, microservice cũng có nhược điểm:
● Phải xử lý sự cố khi kết nối chậm, lỗi khi thông điệp không gửi được
hoặc thông điệp gửi đến nhiều đích đến vào các thời điểm khác nhau.
● Kiểm thử tự động một dịch vụ trong kiến trúc microservices đôi khi
yêu cầu phải chạy cả các dịch vụ nhỏ khác mà nó phụ thuộc.
26

Nhóm 4: Docker

● Nếu một mắt xích có giao tiếp API thay đổi, liệu các mắt xích khác có
phải thay đổi theo không?
● Triển khai dịch vụ microservices nếu làm thủ công theo cách đã làm
với ứng dụng một khối phức tạp hơn rất nhiều.
● Xem thêm: Introduction to Microservice. [2.5]
● Xem thêm: Introduction to Microservice (bản dịch).[2.6]
4.2.1.3. Hybrid
Do các container thường chỉ thực hiện một chức năng nhất định, ứng dụng
mô hình microservice, các container có thể chạy ở bất kì đâu, miễn là chúng
có đủ điều kiện kết nối với nhau.
Trong trường hợp muốn tận dụng từng ưu điểm hoặc tối ưu chi phí khi sử
dụng dịch vụ của các nhà cung cấp dịch vụ cloud (cloud provider), hoàn toàn
có thể thiết lập mô hình hybrid.
4.2.2. Stateful Application
Ngược lại với stateless, server cần lưu dữ liệu của client, điều đó đồng nghĩa
với việc ràng buộc giữa client và server vẫn được giữ sau mỗi yêu cầu
(request) của client. Data được lưu lại phía server có thể làm input
parameters cho lần kế tiếp.
Khi chạy những ứng dụng stateful trên docker, nếu một container bất ngờ
hỏng, toàn bộ dữ liệu về session trong container đều bị mất. Với những trang
web về kinh doanh, điều này không được phép xảy ra.
Để khắc phục tình trạng trên, chỉ còn một cách duy nhất, đó là đưa thông tin
về session lưu ra ngoài container, và ứng dụng stateful sẽ trở thành stateless
và ứng dụng tương tự PART I/ 4.2.1. Stateless Application.
27

Nhóm 4: Docker

PART II: CONTAINER NETWORKING
1. Challenge
Docker đã phát triển một phương thức tiếp cận với các ứng dụng, cùng với
đó là cách tiếp cận mới với networking. Để làm được như vậy, cần phải thiết
kế những tính năng đảm bảo được các tiêu chí, bao gồm:
● Portability:
○ Làm sao để xây dựng một giao thức mạng duy nhất chạy được
trên các môi trường mạng khác nhau.
● Service Discovery:
○ Làm sao để biết các service đang nằm ở đâu, và trạng thái scale
của chúng.
● Load Balancing:
○ Làm sao để chia sẻ công việc trong một cluster cung cấp cùng
một service.
● Security:
○ Internal: Làm sao để ngăn các container truy cập lẫn nhau
(trong trường hợp cần thiết).
○ External: Làm sao biết được rằng các container chạy ứng dụng
và control đảm bảo tính bảo mật với bên ngoài.
● Performance:
○ Giảm thiểu độ trễ (latency) và tối đa băng thông (bandwidth).
● Scalability:
○ Làm sao để ứng dụng hoạt động bình thường khi các container
được triển khai trên nhiều máy (host) khác nhau.
2. Container Networking Model
2.1. Overview
Kiến trúc mạng của Docker (Docker Networking Architecture) được xây
dựng trên một bộ interface được gọi là Container Networking Model (CMN).
CMN hướng đến mục tiêu cung cấp tính di động (portability) của ứng dụng
trên các cơ sở hạ tầng đa dạng. Mô hình bao gồm ba thành phần chính:
● Sandbox
● Endpoint
● CNM Driver Interfaces
28

Nhóm 4: Docker

Hình 2.1. Container networking model.
2.2. Sandbox
Sandbox là một kĩ thuật quan trọng trong lĩnh vực bảo mật có tác dụng cô
lập các ứng dụng, ngăn chặn các phần mềm độc hại để chúng không thể
làm hỏng hệ thống máy tính, hay cài cắm các mã độc nhằm ăn cắp thông
tin cá nhân của bạn.

Hình 2.2. With and without sandbox.
Bằng cách sử dụng sandbox, máy chủ chạy docker sẽ không quá lo về việc bị
tấn công từ tầng ảo hóa. Tuy nhiên, tương tự như các chương trình diệt virus,
nó chỉ ngăn chặn được những malware đã được biết trước, với những loại
chưa từng gặp thì rất yếu.
Trên thực tế, Sandbox đã được ứng dụng rất nhiều trong các máy ảo, hay
một số trình duyệt như Chrome, FireFox,...
● Xem thêm Những điều cơ bản về sandbox. [2.7]
● Xem thêm Sand box là gì và cách sử dụng. [2.8]
29

Nhóm 4: Docker

2.3. Endpoint
Endpoint theo đúng tên của nó, là một điểm để truy cập đến Container và
tồn tại dưới dạng URL.

Hình 2.3. Docker endpoint.
2.4. CNM Driver Interfaces

Hình 2.4. Docker interfaces.
Các thư viện của Docker network được xây dựng dựa trên các driver. Mỗi khi
thực hiện một chức năng trong thư viện, nó sẽ gọi đến driver phù hợp để
thực hiện chức năng đó.
Có 2 open interfaces được cung cấp giúp cho người dùng, cộng đồng hay
nhà cung cấp (vendor) đều có thể đóng góp công sức phát triển. Các
interface bao gồm:
● Network driver
○ native
○ remote
● IPAM driver (IP Address Management driver)
30

Nhóm 4: Docker

2.4.1. Native network driver
Native network driver (NND) là một phần trong Network driver, mỗi một
NND được xây dựng để giải quyết ít nhất một vấn đề trong chủ đề Docker
networking.
2.4.1.1 Host
Host driver cho phép container sử dụng các tầng mạng của máy chủ vật lý.
Các container có quyền sử dụng trực tiếp toàn bộ các network interfaces mà
máy chủ có.
2.4.1.2 Bridge
Bridge driver tạo một Linux bridge trên host và được quản lý bởi Docker. Mặc
định, các container trong cùng một host có thể giao tiếp (communicate) với
nhau. Kết nối External cũng có thể được cài đặt thông qua bridge driver.

Hình 2.5. Docker bridge driver.
Linux bridge có thể coi là một thiết bị được ảo hóa từ layer 2 switch bên
trong linux kernel. Nó chuyển tiếp (forward) các luồng dữ liệu (traffics) dựa
trên địa chỉ MAC (trong trường hợp này là địa chỉ MAC ảo của container). Tuy
nhiên Bridge trong Docker được triển khai ở mức cao hơn Linux bridge
thông thường.
Về cơ bản, có thể hiểu bridge đóng vai trò như một switch trong mạng vật lý,
hỗ trợ cả kết nối internal và external.
2.4.1.3 Overlay
Overlay driver có vai trò tạo ra một mạng bao phủ (overlay network) giữa các
host khác nhau, từ đó, các container ở các host khác nhau cũng có thể giao
tiếp được với nhau internal trong phạm vi mạng vật lý giữa các host. Nhờ vậy
31

Nhóm 4: Docker

mà dữ liệu chỉ trao đổi trong cluster mà không cần phải ra ngoài internet,
giúp tăng tính bảo mật và tối ưu băng thông ra mạng ngoài.

Hình 2.6. Docker overlay driver.
2.4.1.4 MACVLAN
MACVLAN driver sử dụng MACVLAN Bridge mode để tạo ra các sub-
interface trên card mạng thật của host và cấp địa chỉ IP dựa trên địa chỉ MAC
ảo của container. Và đương nhiên, có hỗ trợ trunking để các container trong
cùng một VLAN nằm trên các host khác nhau có thể kết nối tới nhau.

Hình 2.7. MACVLAN driver.
2.4.1.5 None (Isolated)
Khi chỉ cần sử dụng một container, các driver kể trên không còn quá cần
thiết, việc sử dụng chúng không mang lại nhiều lợi ích. Khi đó, các driver về
Network không còn cần thiết để docker sử dụng nữa, thay vào đó, chúng
được giảm tải để tăng cường hiệu suất công việc..
32

Nhóm 4: Docker

2.4.2. Remote network driver
2.4.2.1. Docker remote network driver
Ngoài các Native networking driver được tích hợp sẵn trong Docker Engine,
chúng ta còn có các Remote networking driver được cộng đồng và các nhà
cung cấp phát triển, rất tương đồng với mô hình mạng Container (CNM). Mỗi
một Driver lại cung cấp những khả năng cũng như dịch vụ mạng của
container một cách riêng.
Có thể kể đến: contiv, weave, calico, kuryr,...
Contiv: là một plugin mã nguồn mở về mạng, được phát triển bởi Cisco,
cung cấp cơ sở hạ tầng cũng như các chính sách bảo mật cho việc triển khai
bằng microservice cho nhiều bên thuê. Contiv cũng cung cấp dịch vụ tích
hợp non-container workloads với các mạng vật lý, chẳng hạn như Cisco ACI
network. Contiv cũng có Remote network drivers và Remote IPAM drivers.
Weave: là một network plugin cho phép tạo một mạng ảo kết nối các
container của Docker thông qua nhiều máy chủ (hosts) hoặc qua clouds.
Weave cung cấp khả năng tự động phát hiện các ứng dụng, có thể hoạt
động trên các mạng có kết nối một phần, không có yêu cầu một nơi lưu trữ
các external cluster và còn thân thiện với người dùng, dễ sử dụng.
Calico: là một giải pháp mã nguồn mở cho các mạng ảo trong các trung
tâm dữ liệu đám mây. Mục tiêu mà Calico hướng tới là các trung tâm dữ liệu
nơi mà hầu hết các Workload (VMs, container hoặc bare-metal servers) chỉ
yêu cầu kết nối IP. Calico cung cấp kết nối này bằng cách sử dụng định
tuyến IP tiêu chuẩn. Sự cô lập giữa các workload - cho dù theo quyền sở hữu
của người thuê hoặc bất kỳ chính sách chi tiết nào hơn - đều đạt được thông
qua lập trình iptables trên các máy chủ lưu trữ các workload nguồn và đích.
Kuryr: là một network plugin được phát triển như một phần của dự án
OpenStack Kuryr. Nó bổ sung cho API của Docker networking (libnetwork)
remote driver bằng cách sử dụng Neutron (dịch vụ mạng của OpenStack).
Kuryr bao gồm một trình điều khiển IPAM.
2.4.2.2. Docker Remote IPAM Drivers
IPAM driver được cộng đồng và các nhà phát triển tạo ra để có thể được sử
dụng nhằm cung cấp tích hợp với các hệ thống sẵn có hoặc các khả năng
đặc biệt khác. (Để rõ hơn về IPAM xin mời đến mục 2.4.3)
IPAM driver tiêu biểu có thể kể đến ở đây là Infoblox.
Infoblox: là một mã IPAM driver mã nguồn mở, cung cấp tích hợp với các
công cụ Infoblox hiện có. Infoblox cung cấp dịch vụ quản lý địa chỉ IP tập
33

Nhóm 4: Docker

trung được kết nối với container networking thông qua một thư viện du
Docker cung cấp tên là Libnetwork.
2.4.3. IP address management (IPAM)
IPAM (IP Address Management) là tính năng đã được giới thiệu từ Windows
Server 2012 cung cấp khả năng quản lý và giám sát tùy biến cao cho các cơ
sở hạ tầng địa chỉ IP trong hệ thống mạng. IPAM có thể để phát hiện, theo
dõi, giám sát và quản lý không gian địa chỉ IP được sử dụng trên mạng. IPAM
cung cấp cho người quản trị khả năng giám sát các server chạy Dynamic
Host Configuration Protocol (DHCP) và Domain Name System (DNS). Với
IPAM, quản trị viên có thể đảm bảo rằng kho lưu trữ các địa chỉ IP đã được
đăng ký vẫn còn nguyên vẹn và đầy đủ.
Quản trị viên mạng sử dụng IPAM để xác định và cập nhật các chi tiết khác
nhau về mạng của họ, chẳng hạn như:
● Có bao nhiêu không gian địa chỉ IP miễn phí tồn tại.
● Những mạng con (subnet) nào đang được sử dụng, chúng lớn như
thế nào và ai sử dụng chúng.
● Tình trạng vĩnh viễn so với tạm thời cho mỗi địa chỉ IP.
● Các bộ định tuyến (router) mặc định mà các thiết bị mạng khác nhau
sử dụng.
● Tên máy chủ (host) được liên kết với mỗi địa chỉ IP.
● Phần cứng (hardware) cụ thể liên quan đến từng địa chỉ IP.
3. Container Management Tools
3.1. Docker Compose
3.1.1. Overview
Compose là công cụ giúp định nghĩa và chạy các ứng dụng multi-container
Docker. Với Compose, bạn sử dụng tệp YAML để cấu hình các dịch vụ của
ứng dụng, rồi tạo và bắt đầu tất cả các dịch vụ từ cấu hình đó với một lệnh
duy nhất.
Compose là một công cụ tuyệt vời không chỉ dùng cho development,
testing, staging environments, mà còn ứng dụng trong CI workflows. Việc sử
dụng Docker Compose được tóm lược trong 3 bước cơ bản sau:
● Khai báo môi trường ứng dụng với Dockerfile.
● Khai báo các dịch vụ để chạy ứng dụng trong docker-compose.yml.
● Chạy lệnh docker-compose up.
Ví dụ về docker-compose.yml:
1. version: '3'
34

Nhóm 4: Docker

2. services:
3. web:
4. build: .
5. ports:
6. - "5000:5000"
7. volumes:
8. - .:/code
9. - logvolume01:/var/log
10. links:
11. - redis
12. redis:
13. image: redis
14.volumes:
15. logvolume01: {}
Compose có các lệnh sau để quản lý vòng đời của ứng dụng:
● Start, stop, rebuild.
● Xem trạng thái của các dịch vụ đang chạy.
● Stream log output của các dịch vụ đang chạy.
● Chạy lệnh một lần trên một dịch vụ.
3.1.2. Get started
Một ví dụ về việc xây dựng một ứng dụng web Python đơn giản chạy trên
Docker Compose. Ứng dụng sẽ sử dụng Flask framework và duy trì bộ đếm
trong Redis.
3.1.2.1. Setup
Tạo thư mục cho project:
1. $ mkdir composetest
2. $ cd composetest
Tạo app.py trong thư mục project với nội dung sau:
1. from flask import Flask
2. from redis import Redis
3.
4. app = Flask(__name__)
5. redis = Redis(host='redis', port=6379)
6.
7. @app.route('/')
8. def hello():
9. count = redis.incr('hits')
10. return 'Hello World! I have been seen {}
times.n'.format(count)
11.
12.if __name__ == "__main__":
35

Nhóm 4: Docker

13. app.run(host="0.0.0.0", debug=True)
Tạo requirements.txt trong project directory với nội dung sau:
1. flask
2. redis
3.1.2.2. Create a Dockerfile
Trong bước này chúng ta tiến hành viết Dockerfile để build ra Docker image.
Image này chứa toàn bộ các phụ thuộc mà ứng dụng Python yêu cầu, bao
gồm cả chính Python.
Trong thư mục project, tạo file name: Dockerfile và paste nội dung sau vào:
1. FROM python:3.4-alpine
2. ADD . /code
3. WORKDIR /code
4. RUN pip install -r requirements.txt
5. CMD ["python", "app.py"]
Chúng ta có thể hiểu đơn giản thành các bước sau:
● Build một image từ image Python 3.4 có sẵn trên Docker hub.
● Thêm thư mục hiện tại vào thư mục /code bên trong image.
● Thiết lập thư mục làm việc với Docker thành /code.
● Install các Python dependencies.
● Đặt lệnh mặc định của container là python app.py.
3.1.2.3. Define services in a Compose file
Tạo docker-compose.yml trong thư mục project với nội dung sau:
1. version: '2'
2. services:
3. web:
4. build: .
5. ports:
6. - "5000:5000"
7. volumes:
8. - .:/code
9. redis:
10. image: "redis:alpine"
Compose file khai báo 2 services, web & redis:
● Sử dụng image được build từ Dockerfile trong thư mục project.
● Forward port 5000 của container sang port 5000 trên host machine.
● Mounts thư mục project trên host sang /code bên trong container,
cho phép bạn chỉnh sửa code mà không cần rebuild image.
36

Nhóm 4: Docker

3.1.2.4. Build and run your app with Compose
Start ứng dụng từ thư mục project:
1. $ docker-compose up
2. Pulling image redis...
3. Building web...
4. Starting composetest_redis_1...
5. Starting composetest_web_1...
6. redis_1 | [8] 02 Jan 18:43:35.576 # Server started, Redis version
2.8.3
7. web_1 | * Running on http://0.0.0.0:5000/
8. web_1 | * Restarting with stat
Compose kéo Redis image về host và tiến hành build một image cho code,
sau đó start services bạn đã khai báo.
Vào địa chỉ http://0.0.0.0:5000/ trên trình duyệt sẽ thấy ứng dụng đang chạy.
Nếu bạn sử dụng Docker trên Linux, bạn cũng có thể thử vào bằng đường
dẫn sau: http://localhost:5000. Nếu bạn sử dụng Docker Machine trên Mac,
hãy dùng lệnh docker-machine ip MACHINE_VM để lấy IP address của Docker
host. Sau đó vào bằng đường dẫn sau: http://MACHINE_VM_IP:5000.
Bạn sẽ thấy message sau trên trình duyệt, nếu refresh web page, số lượng
view sẽ tăng lên:
1. Hello World! I have been seen 1 times.
3.1.2.5. Update the application
Như đã đề cập trong 3.1.2.3, application code đã được mount vào trong
container volume, chính vì thế lập trình viên có thể chỉnh sửa code và thấy sự
thay đổi này diễn ra tức thì mà không cần rebuild the image.
Sửa code ﬁle app.py và save lại:
1. return 'Hello from Docker! I have been seen {}
times.n'.format(count)
Refresh page và mọi thứ đã được cập nhật.
3.1.2.6. Experiment with some other commands
Nếu bạn muộn khởi chạy các services bên trong background, hãy thêm flag
-d (for “detached” mode) vào lệnh docker-compose up và sử dụng lệnh
docker-compose ps để thấy những gì đang chạy trên host.
1. $ docker-compose up -d
2. Starting composetest_redis_1...
3. Starting composetest_web_1...
4.
5. $ docker-compose ps
37

Nhóm 4: Docker

6. Name Command State Ports
7. ----------------------------------------------------------------
8. composetest_redis_1 /usr/local/bin/run Up
9. composetest_web_1 /bin/sh -c python app.py Up 5000->5000/tcp
Câu lệnh docker-compose run cho phép ta chạy 1 lần nhiều câu lệnh cho các
services. Ví dụ để thấy các environment variables trên web service:
1. $ docker-compose run web env
Dùng docker-compose –help để xem các câu lệnh có sẵn khác.
Nếu bạn started Compose với docker-compose up -d bạn có thể sẽ cần stop
các services, khi đó hãy dùng lệnh:
1. $ docker-compose stop
Bạn có thể xóa tất cả các container. Truyền vào –volumes để remove data
volume được dùng bởi Redis container:
1. $ docker-compose down --volumes
3.2. Docker Swarm
3.2.1. Overview
Khi số lượng container tăng lên, việc quản lý, triển khai, scale trở nên phức
tạp, không thể hì hục chạy bằng tay được thì chúng ta cần đến Docker
Swarm. Docker swarm là một công cụ giúp chúng ta tạo ra một clustering
Docker (cụm các máy chạy Docker). Nó giúp chúng ta gom nhiều Docker
Engine lại với nhau và ta có thể "nhìn" nó như duy nhất một virtual Docker
Engine.
● Docker Swarm có khả năng khởi chạy các container trên nhiều máy
(cluster - máy ảo hoặc máy vật lý) hoặc trên một máy duy nhất
(standalone)
● Nó là một phần mềm hỗ trợ việc tạo và quản lý các container hoặc các
hệ thống Container Orchestration. Nó là một cluster nơi mà người
dùng quản lý các Docker Engines hoặc các node nơi mà các service
được deploy và chạy.
● Ngoài ra Docker Swarm có những tính năng để hỗ trợ việc quản lý các
container khi chạy trên môi trường phân tán và để chắc chắn các
container trong một cluster hoạt động ổn định.
3.2.2. Swarm Architecture
Docker Swarm là một cụm (cluster) các máy (máy thật hoặc máy ảo) cùng
chạy Docker tập hợp lại với nhau. Mỗi máy gọi là một node. Có 2 loại nodes:
managers và workers.
38

Nhóm 4: Docker

● Máy khởi tạo swarm nắm quyền kiểm soát toàn bộ swarm và máy đó
gọi là manager node. Mọi câu lệnh Docker sẽ được thực thi trên
Swarm manager.
● Các máy tham gia vào swarm được gọi là worker node. Các node này
chỉ có khả năng cung cấp khả năng hoạt động chứ không có quyền
quản lý các node khác.
3.2.2.1. Important concept in Docker swarm
Kiến trúc Docker Swarm bao gồm các "manager" và các "worker". Người
dùng có thể khai báo trạng thái mong muốn của nhiều service để chạy
trong Swarm cluster sử dụng YAML files. Đây là vài thuật ngữ thông dụng
liên quan đến Docker Swarm:
● Node: Một node là một thực thể của Swarm, các node có thể được
phân phối tại chỗ hoặc trên cloud.
● Swarm: một cluster của các node. Trong chế độ Swarm, bạn sắp đặt
các service, thay vì chạy các container bằng câu lệnh.
● Manager node: Là node nhận các định nghĩa service từ người dùng, và
gửi công việc đến các node Worker. Node Manager có thể cũng thực
hiện công việc của các node Worker.
● Worker node: là node nhận và chạy các nhiệm vụ từ node Manager.
● Service: Một service xác định images của container mà số lượng các
bản lặp lại.
● Task: một task là một nhiệm vụ của service trong một node worker.
3.2.2.2. Features
Docker Swarm cung cấp cho chúng ta rất nhiều tính năng nổi bật ví dụ như :
● Quản lý cluster với Docker Engine
● Thiết kế phân cấp
● Scaling
● Multi-host networking
● Service discovery
● Load balancing
● Bảo mật
● Rolling updates
3.2.2.3. How nodes work?
Các node trong Docker Swarm là các máy chạy Docker Engine được join vào
swarm. Các node này có thể được gọi là một Docker Node.
Để có thể deploy một ứng dụng trên Swarm, người dùng cần phải định
nghĩa các service đến manager node. Manager node này sẽ chuyển service
này thành các task và đưa xuống cho các node bên dưới để thực thi.
39

Nhóm 4: Docker

Docker Swarm còn được coi là một dạng native cluster do các node trong
cluster kể cả là manager node cũng sẽ hoạt động như một worker node. Các
worker node được giao task từ manager node sẽ thông báo về cho manager
node tình trạng hiện tại của task đang chạy trên node đó thông qua một
*agent* ở mỗi node để cho manager node có thể đảm bảo trạng thái của
mỗi node bên dưới nó.

Hình 3.1. Docker Swarm architecture.
3.2.2.4. Service and Task in Docker Swarm
● Service trong Docker Swarm đảm nhận chức năng định danh các task
hoạt động cho manager node hoặc các worker node.
● Ngoài docker-CLI thì các service này cũng có thể được deploy bằng
Docker-Compose.
● Khi khởi tạo một service trong swarm mode, người dùng sẽ xác định
container imager nào sẽ được sử dụng và câu lệnh nào sẽ chạy bên
trong container đó.
● Các container images được chia sẻ và upload trên Docker hub.
● Một task có nhiệm vụ xác định Docker container và câu lệnh sẽ được
chạy bên trong container đó.
● Node manager sẽ đưa các task này cho các worker node theo số
lượng replicas được set trong service scale. Khi một task được đưa cho
một worker node, nó sẽ không thể chuyển sang node khác, nó chỉ có
thể trên node được manager node chỉ định hoặc FAIL.
● Có 2 kiểu service là:
○ Replicated Service: ở chế độ này thì swarm manager sẽ xác
định số lượng các bản sao mà một task của một service sẽ được
chạy trên các nodes dựa theo sự mong muốn của người dùng.
○ Global Services: ở chế độ này swarm manager sẽ chạy một task
cho một service trên tất cả các node có khả năng chạy được
trong cluster.
40

Nhóm 4: Docker

● Ngoài ra, nếu người dùng tạo một service mà trong cluster hiện tại
chưa có node nào có khả năng chạy service đó thì service đó sẽ được
đưa về chế độ Pending Service.
● Service có thể bị Pending mãi mãi nếu không có node nào trong
cluster có khả năng thỏa mãn yêu cầu sử dụng của service.
3.2.2.5. Docker Swarm Network
● Trong Docker Swarm có 2 kiểu trafﬁc khác nhau là:
○ Control and management plane traffic: Đây là traffic luôn luôn
bị được mã hóa vì nó chứa các Swarm management message ví
dụ như các request tham gia hoặc rời bỏ Swarm.
○ Application data plane traffic: Đây là traffic của các container và
các giao thức kết nối ra các clients bên ngoài.
● Docker Swarm sử dụng 3 loại network là user define network,
docker_gwbridge, ingress.
3.2.2.6 Docker Swarm Volume
● Docker Swarm Volume là nơi chứa tập hợp các data trong cluster và
sử dụng nó cho Swarm Cluster thông qua việc bind-mount volume.
Tất cả các task sẽ sử dụng data trong volume được mount.
● Mặc định thì các volume trong swarm sẽ được đặt ở local. Do vậy các
volume trong các node là hoàn toàn tách biệt và Docker hỗ trợ sử
dụng các volume plugins sử dụng các phần mềm như GFS, Ceph, NFS
nếu người dùng muốn sync data giữa các node. Tất cả các data ở
trong local volume sẽ bị mất nếu container hoặc node bị reset.

Hình 3.1.1. Docker Swarm Volume.

41

Nhóm 4: Docker

3.3. Kubernetes
3.3.1. Overview
3.3.1.1. What is Kubernetes?
Kubernetes là một mã nguồn mở được dùng để tự động triển khai hệ thống,
scaling, quản lý các container. Nó thực sự là một hệ thống mạnh mẽ, được
phát triển bởi Google. Google sử dụng Kubernetes để quản lý hàng tỉ docker
container mà họ đang quản lý.
Kubernetes là một Container scheduler và hơn thế nữa. Chúng ta có thể
dùng nó để triển khai các dịch vụ của chúng ta, để roll-out các bản release
mới mà không bị downtime hoặc để mở rộng (scale out) và thu hẹp (scale in)
các dịch vụ này. Nó có thể chạy trên private cloud hoặc các public cloud, từ
các máy chủ siêu khủng cho đến các máy chủ mini như Raspberry Pi. Nó có
thể triển khai ở môi trường on-premise hoặc hybrid. Chúng ta có thể di
chuyển cụm Kubernetes Cluster từ nhà cung cấp dịch vụ lưu trữ này sang
nhà cung cấp dịch vụ lưu trữ khác mà không thay đổi (gần như) bất kỳ quy
trình triển khai và quản lý nào. Kubernetes có thể dễ dàng mở rộng để phục
vụ gần như mọi nhu cầu. Chúng ta có thể chọn module nào chúng ta sẽ sử
dụng và chúng ta có thể tự phát triển các tính năng bổ sung và plug chúng
vào.
Việc triển khai không thời gian downtime hệ thống, khả năng chịu lỗi, tính
sẵn sàng cao, khả năng mở rộng cao và tự phục hồi là quá đủ để thấy giá trị
trong Kubernetes. Danh sách những gì Kubernetes làm được là rất nhiều và
tăng nhanh. Cùng với Docker, nó đang trở thành một nền tảng bao trùm
toàn bộ vòng đời phát triển, triển khai và phân phối phần mềm.
3.3.1.2. Who is using Kubernetes?
● Các doanh nghiệp lớn, có nhu cầu thực sự phải scaling hệ thống
nhanh chóng, và đã sử dụng container (Docker).
● Các dự án cần chạy >= 5 container cùng loại cho 1 dịch vụ. (Ví dụ dùng
5 máy hoặc nhiều hơn cùng để chạy code website XYZ). Còn nhỏ hơn
thì tốt nhất không dùng.
● Các startup hiện đại, chịu đầu tư vào công nghệ, để nhỡ về sau có to
ra, thì rất dễ scaling.
● Các sysadmin/DevOps muốn tăng lương, tìm một công việc tốt hơn,
hay đơn giản là mày mò công nghệ mới.
3.3.1.3. Kubernetes distributions
Một số provider có cung cấp Kubernetes
● CoreOS Tectonic/Red Hat CoreOS: https://coreos.com/tectonic/
● RedHat Openshift: https://www.openshift.com/
42

Nhóm 4: Docker

● Google container engine (GKE): https://cloud.googl...container-engine/
(free $300 cho tài khoản mới - dùng hết thì thôi cũng được)
3.3.2. Kubernetes Architecture
Có một tập hợp các tiến trình core của Kubernetes tạo dựng lên cụm cluster
và trong đó có thành phần chính đó là:
● Kubernetes Master (Control Plane)
● Kubernetes Node (Minion)

Hình 3.2. Sơ đồ của cụm Kubernetes cluster.
3.3.2.1. Kubernetes Master (Control Plane)
● Kube-apiserver: Đóng vai trò như một API Server, cung cấp truy cập
đến Kubernetes API.
● Kube-controller-manager: Chạy các Controller, xử lý các background
task.
● Kube-scheduler: Cấp phát các Pod ở các Node theo các tiêu chí nhất
định.
(Pod là 1 nhóm (1 trở lên) các container thực hiện một mục đích nào đó, như
là chạy software nào đó. Nhóm này chia sẻ không gian lưu trữ, địa chỉ IP với
nhau. Pod thì được tạo ra hoặc xóa tùy thuộc vào yêu cầu của dự án. )
● Cloud-controller-manager: Chạy các Controller giao tiếp với các nhà
cung cấp dịch vụ cloud (ví dụ: Google Cloud, AWS,..).
● Etcd: Kho lưu trữ key-value phân tán. Toàn bộ dữ liệu của Kubernetes
Cluster đều lưu trên đây vậy nên nó rất quan trọng và cần sao lưu
thường xuyên.
3.3.2.2. Kubernetes Node (Minion)
● Kubelet: Chạy trên mỗi node, nhiệm vụ quản lý các Pod trên node đó.
43

Nhóm 4: Docker

● Kube-proxy: ĐỊnh tuyến các kết nối đến Pod và cân bằng tải (load
balancing).
3.3.2.3. Important concepts in Kubernetes
Trong Kubernetes có rất nhiều các thành phần cũng như khái niệm, tuy
nhiên ở đây ta sẽ chỉ liệt kê các thành phần, khái niệm cơ bản và quan trọng
nhất trong kiến trúc Kubernetes.
1. Label and Selector in Kubernetes
● Label (nhãn) là một trong những khái niệm Kubernetes cơ bản.
Label là một cặp key-value gắn vào một Kubernetes Resource.
Và mỗi Kubernetes Resource có thể có một hoặc nhiều label.
Label phục vụ như một phương tiện để xác định một cụ thể
một Resource hoặc tập hợp các Resource.
● Label Selector cũng là các cặp key-value. Chúng dùng để chọn
một label nhất định hoặc một tập hợp các label. Theo cơ chế
này, một loại Resource có thể chọn (select) một hoặc nhiều các
Resources thuộc loại khác. Label còn được dùng với kubectl để
truy vấn các loại Resource nhất định.
Sơ đồ sau mô tả cơ chế lựa chọn này với Service chọn một nhóm Pod
qua selector.

Hình 3.3.1: Service chọn một nhóm Pod qua Selector
2. Kubernetes Resources
Resource là trừu tượng (abstraction) ở mức cao chứa trạng thái khai
báo (declarative) cho một thành phần cơ sở hạ tầng (infrastructure).
Resource trong Kubernetes được publish vào kube-apiserver và nó là
trách nhiệm của các Kubernetes Controller để đưa Cluster vào đúng
với các trạng thái đã khai báo.
Có rất nhiều loại Resource khác nhau trong Kubernetes, danh sách
đầy đủ các Resource có thể xem ở tài liệu API của Kubernetes [2.9].
Các phần dưới đây chỉ giới thiệu các loại Resource quan trọng.
44

Nhóm 4: Docker

● Workload resources
○ Pod: Pod là một đơn vị thực thi cơ bản và nhỏ nhất trong
Kubernetes. Pod có thể có một hoặc nhiều container.
○ Deployment and ReplicaSet:
■ Deployment: thì quản lý vòng đời của các Pod và
một resource tên ReplicaSet. Nó cho phép cập
nhật một ứng dụng đang chạy mà không có
downtime. Có chiến lược khởi động lại Pod thi
chúng die hoặc crash.
■ ReplicaSet: được tạo ra khi Deployment được tạo,
dùng như định nghĩa để tạo Pod.

Hình 3.3.2: Deployment và ReplicaSet.
○ DaemonSet: Đảm bảo một Pod chạy trên các Node đã
sẵn sàng.
○ StatefulSet: Quản lý tập hợp các Pod về việc deployment
và scaling, được đảm bảo theo thứ tự và tính duy nhất,
thường được sử dụng ở các database cluster phân tán.
○ Job: Job tạo nên một hoặc nhiều Pod đảm bảo rằng ít
nhất một lượng nhất định trong số chúng chạy đến khi
45

Nhóm 4: Docker

hoàn thành. Sử dụng Job trong Kubernetes khi muốn
chạy tiến trình một lần, vì khi chạy xong container sẽ
không được khởi động lại.
○ CronJob: chạy Job theo lịch đã định sẵn.
● Discovery and Load Balancing resources
○ Server(svc): Nhóm lại một hoặc nhiều Pod bằng Label
Selector. Nó cung cấp ClusterIP và DNS cho các Pod.

Hình 3.3.3: Service chọn một nhóm Pod qua Selector.
○ Ingress: dùng để cấu hình Ingress Controller (là một
reverse proxy), vì thế Service có thể truy cập từ phía ngoài
Cluster.
● Config, Storage and Cluster resources
○ ConfigMap: Cho phép lưu file config độc lập ko phụ
thuộc với container image.

Hình 3.3.4: Cấu trúc của ConﬁgMap.
○ Secret: Lưu pass, token, key, riêng biệt.

Hình 3.3.5: Cấu trúc của Secret
○ Volume, PersistentVolume và PersistentVolumeClaim
46

Nhóm 4: Docker

■ Volume: Là thư mục chứa dữ liệu, là một thành
phần của Pod, tồn tại theo Pod. Tạo ra
PersistentVolume (PV) và PersistentVolumeClaim
(PVC).
■ PV rất hữu ích khi quản lý tài nguyên lưu trữ cho
các dự án lớn. PV có vòng đời độc lập với Pod, PVC
tiêu thụ tài nguyên của PV, tương tự cách Pod tiêu
thụ tài nguyên của Node.

Hình 3.3.6: Volume, PersistentVolume và PersistentVolumeClaim.
○ NameSpace: Là nơi để đặt tất cả lại với nhau. Gần giống
như một môi trường.

Hình 3.3.7: Cấu trúc NameSpace
47

Nhóm 4: Docker

PART III: DEMO SCENARIO
Trong phần này, chúng tôi sẽ trình bày các công dụng hữu ích nhất của
Docker qua từng tình huống. Bắt đầu từ việc xây dựng image, container từ
file Dockerfile đơn giản tới Docker Compose, sau đó phức tạp hơn sẽ là
Docker Swarm. Bằng cách trên, chúng tôi chỉ ra các điểm thuận lợi, không
thuận lợi của từng loại.
Trong tình huống đầu tiên, chúng tôi sẽ làm quen với Docker bằng dòng
lệnh. Kết thúc quá trình, service nginx để phục vụ nội dung Web được khởi
tạo và có thể truy cập từ bên ngoài.
Trong tình huống tiếp theo, chúng tôi sẽ hướng dẫn cài đặt và sử dụng
docker-compose để tạo dịch vụ web tương tự tình huống trước. Sau đó,
chúng tôi giới thiệu về Play with Docker để mọi người có thể làm quen với
Docker một cách thuận tiện, nhanh chóng.
Cuối cùng, chúng tôi đưa ra tình huống kết hợp cả Dockerfile,
docker-compose, và docker swarm để mô phỏng lại quá trình phát triển
phần mềm kết hợp CI/CD thông qua một ứng dụng bình chọn đơn giản.
Cấu hình phần mềm yêu cầu: Để thuận tiện trong thao tác, tất cả các máy
tính ảo/vật lý đều được cài đặt hệ điều hành (OS) Ubuntu 18.04 x64. Do vậy
các lệnh được thực hiện trong hệ điều hành thống nhất là Ubuntu. Đối với
các hệ điều hành khác, có thể cần sử dụng câu lệnh khác.
Quy ước: chúng tôi sử dụng user root để thuận tiện trong việc trình bày.
Trong thực tế, chúng tôi không khuyến khích sử dụng khi không cần thiết.
Đối với dấu nhắc lệnh (shell) bash:
1. root@batman #
Giải thích:
● root : user/người dùng hiện tại
● batman : hostname của máy hiện tại
● # : quyền hạn cao nhất
Một số các script, ﬁle được lưu trữ tại : https://gitlab.com/tramanh/docker101/
1. From Dockerfile
1.1. Install & Start Docker
Có thể lựa chọn 1 trong nhiều cách cặt đặt, chi tiết tham khảo [Get Docker
CE for Ubuntu] (https://docs.docker.com/install/linux/docker-ce/ubuntu/)
Sử dụng kênh cài đặt của Docker
48

Nhóm 4: Docker

1. # Download Docker
2. curl -fsSL get.docker.com -o get-docker.sh
3. # Install Docker using the stable channel
4. # (instead of the default "edge")
5. CHANNEL=stable sh get-docker.sh
6. # Remove Docker install script
7. rm get-docker.sh
Sau khi cài đặt thành công, khởi động service và kiểm tra trạng thái:
1. root@hackerman # service docker start
2. root@hackerman # service docker status

1.2. Demo
Trong tình huống này, chúng tôi sẽ xây dựng lại Image từ base image nginx
bằng cách copy nội dung thư mục app vào trong thư mục của base image.
Sau đó tạo container từ image vừa build.
1. # Create app folder
2. mkdir app
3. # Create index file
4. echo Hello Docker > app/index.html
5. # Create Dockerfile
6. echo FROM nginx > Dockerfile
7. echo COPY app/ /usr/share/nginx/html >> Dockerfile
8. # Build Image with tag
9. docker build -t nginx-local .
10.# Start container from Image
11.docker run -d --name nginx-local-c1 -p 8080:80 -t nginx-local
Thực hiện trên Terminal:
49

Nhóm 4: Docker

Từ trình duyệt web truy cập vào IP address của máy đang chạy dịch vụ trên
với port 8080:

Để dừng container:
1. root@hackerman # docker container stop nginx-local-c1

2. To Docker-Compose
2.1. Install docker-compose
Cài đặt docker-compose có thể thực hiện bằng nhiều cách, trong tình huống
này, chúng tôi sử dụng APT của Ubuntu để đơn giản hóa việc cài đặt, tại thời
điểm viết báo cáo, phiên bản docker-compose là 1.17.1 , nên có thể cũ hơn
bản cài đặt thông qua phương pháp khác.
1. root@hackerman # apt update
2. root@hackerman # apt install docker-compose
2.2. Demo
Trong tình huống này, thay vì build image mới dựa trên nginx, chúng tôi sẽ
mount thư mục web vào trong container thông qua “volumes"
Tạo ﬁle docker-compose.yml:
1. web:
2. image: nginx
50

Nhóm 4: Docker

3. volumes:
4. - ./app/:/usr/share/nginx/html/
5. ports:
6. - 8081:80
Tạo thư mục app gồm index.html chứa nội dung “Hello Docker".
Để tạo và up (khởi động) container từ docker-compose, trong thư mục chứa
docker-compose.yml, từ Terminal nhập:
1. root@hackerman # docker-compose build
2. root@hackerman # docker-compose up -d

Từ trình duyệt web truy cập vào IP address của máy đang chạy dịch vụ trên
với port 8081 để xác nhận dịch vụ đã hoạt động.

Để dừng service container:
1. root@hackerman # docker-compose down

Tương tự, cũng sử dụng docker-container, chúng tôi có thể nhanh chóng tạo
ra container từ image trong tình huống trước nginx-local bằng cách thay
đổi giá trị image trong file docker-compose.yml:
51

Nhóm 4: Docker

Như vậy, việc sử dụng docker-compose cũng cho ra kết quả tương tự thao
tác dòng lệnh.
2.3. Introduce Play with Docker
Trong mục này, chúng tôi xin được giới thiệu về Play with Docker
(https://labs.play-with-docker.com/), bên cạnh đó là website Training Play
with Docker Classroom (https://training.play-with-docker.com/).
Play with Docker:
● Sân chơi cho phép người dùng sử dụng các lệnh Docker trong chớp
mắt.
● Cung cấp cho người dùng 1 máy Alpine Linux Virtual Machine miễn
phí ngay bên trong trình duyệt web.
● Có thể tạo các container, thậm chí là cả cluster trong Docker Swarm
Mode.

Play with Docker Classroom:
● Các bài tập thực hành và hướng dẫn trực quan.
● Phù hợp với nhiều đối tượng: (new) Docker users, SysAdmins, IT Pros,
Developers.
52

Nhóm 4: Docker

Để sử dụng cần có account hub.docker.com.
3. Docker Swarm
3.1. Scenario
Ngày nay, công việc phát triển phần mềm hiện đại yêu cầu rất nhiều công
cụ, môi trường làm việc khác nhau. Sau khi lập trình viên hoàn thành công
việc viết mã ban đầu, vẫn còn những giai đoạn khác như kiểm thử phần
mềm (testing), đưa vào môi trường sản phẩm thực tế (production), mỗi một
giai đoạn đều yêu cầu những công cụ đặc biệt. Việc cài đặt tất cả những
công cụ này trên máy tính của những người tham gia giai đoạn phát triển
sản phẩm là lãng phí tài nguyên.
Vì vậy, chúng tôi đưa ra giải pháp dùng Docker như một trợ thủ đắc lực giúp
giảm chi phí tài nguyên, đơn giản hóa các giai đoạn, hỗ trợ quy trình, chuẩn
quá trong việc phát triển, kiểm thử phần mềm.
Mô hình luồng làm việc "Phát triển ứng dụng bình chọn" như sau:

53

Nhóm 4: Docker

1. Developer push commit/code lên hệ thống quản lý mã nguồn sử
dụng Gitlab.
2. Gitlab thực hiện hành động tương ứng dựa trên cấu hình trong
.gitlab-ci.yml định nghĩa:
a. Kiểm tra (test) code: việc test code được thực hiện bởi runner
bằng một Docker sử dụng image python:2.7.

b. Nếu branch là master: build image và push lên Docker Hub;
việc build image được thực hiện bởi runner bằng Docker sử
dụng image docker.
3. Deployment: Thực hiện thủ công, công việc này nhằm đưa image đã
được build thành công từ Docker Hub vào trong Docker Swarm.
3.2. Building backend
Để tình huống sát với thực tế, chúng tôi tạo nhiều VPS (virtual private server
- máy chủ ảo) ở nhiều khu vực vật lý khác nhau, mỗi VPS đều có thông số
hardware (RAM, CPU, Storage) khác nhau.

54

Nhóm 4: Docker

Chúng tôi lặp lại việc thực hiện các thao tác sau trên từng máy để cài đặt
Docker và tăng bộ nhớ SWAP (dung lượng tăng tùy vào phần cứng) cho việc
thực thi các ứng dụng yêu cầu nhiều tài nguyên (Gitlab,..)
1. # Download Docker
2. curl -fsSL get.docker.com -o get-docker.sh
3. # Install Docker using the stable channel
4. # (instead of the default "edge")
5. CHANNEL=stable sh get-docker.sh
6. # Remove Docker install script
7. rm get-docker.sh
8. # Increase SWAP, temporary
9. fallocate -l 4G /swapfile
10.chmod 600 /swapfile
11.mkswap /swapfile
12.swapon /swapfile
13.sysctl -w vm.swappiness=10
14.sysctl vm.swappiness=10
3.2.1. Install Gitlab

Sử dụng docker-compose để tạo container với file cấu hình như trên. Hoàn
thành cài đặt bằng việc thay đổi password quản trị(user root). Bắt đầu tạo
project và đưa code của ứng dụng bình chọn lên.
55

Nhóm 4: Docker

3.2.2. Create Docker Hub Account

3.2.3. Configure Gitlab Runner
Vào Project → Settings → CI/CD → Runners để lấy token cho Runner như hình
dưới, do Runner được phép sử dụng source code của project nên cần bảo vệ
token.
Sau đó sử dụng lệnh để tạo docker container chạy gitlab runner.
56

Nhóm 4: Docker

1. docker run -d
2. --name gitlab-runner
3. --restart always
4. -v gitlab-runner:/etc/gitlab-runner
5. -v /var/run/docker.sock:/var/run/docker.sock
6. gitlab/gitlab-runner:latest
7. docker exec -it gitlab-runner bash
8. export GITLAB_URL=http://git.cloudinthe.space/
9. export GITLAB_TOKEN=kzbCFzq1QJxNzuspVu1a
10.
11.gitlab-runner
12. register -n
13. --name "Docker Runner"
14. --executor docker
15. --docker-image docker:latest
16. --docker-volumes /var/run/docker.sock:/var/run/docker.sock
17. --url $GITLAB_URL
18. --registration-token $GITLAB_TOKEN
19. --tag-list dog-cat-cluster,stag,prod

Sau khi join thành công, trong phần Available shared Runners sẽ xuất hiện
tên và ID của runner vừa tạo.
57

Nhóm 4: Docker

3.2.4. Configure Docker Swarm
Cấu hình của Swarm bao gồm node quản lý và các node làm việc.
Chọn 1 trong số các máy cài Docker Engine để chuyển thành node quản lý
Swarm bằng cách sử dụng lệnh docker swarm init.

Kết quả thực hiện lệnh tạo ra dòng lệnh docker swarm join, sử dụng dòng
lệnh này tại các máy khác sẽ chuyển máy đó thành swarm worker.

Trong trường hợp cần lấy lại token thì sử dụng lệnh sau để lấy token thay vào
trong lệnh swarm join:

Sau khi join các node worker, kiểm tra tại node manager:

Để thuận tiện, chúng tôi sử dụng Portainer (https://www.portainer.io/) cung
cấp giao diện đồ họa hỗ trợ quản trị các node dễ dàng hơn, debug lỗi trực
quan.
Việc cài đặt được thực hiện qua node manager sử dụng Swarm bằng một
dòng lệnh với portainer.yml là ﬁle chứa cấu hình khởi tạo các container.
1. root@hackerman # docker stack deploy -c portainer.yml portainer
Sau khi kích hoạt, Portainer hoạt động ở port 9000 trên node manager:
58

Nhóm 4: Docker

3.3. CI/CD flow
3.3.1. Repository's CI/CD settings
Make .gitlab-ci.yml great again!
Để kích hoạt Gitlab CI/CD, trong project cần có file .gitlab-ci.yml. Bên trong
file này chúng tôi định nghĩa hành vi của Gitlab khi nhận được commit. Cụ
thể là:
1. Kiểm tra (test) code: việc test code được thực hiện bởi runner bằng
một Docker sử dụng image python:2.7.
2. Nếu branch là master : build image và push lên Docker Hub; việc build
image được thực hiện bởi runner bằng Docker sử dụng image docker.
Chúng tôi sử dụng Project → Settings → CI/CD → Variables để bảo vệ thông tin
tài khoản Docker Hub trong quá trình push image. Ví dụ:
● CI_REGISTRY : https://index.docker.io/v1/
● CI_REGISTRY_IMAGE : index.docker.io/dothitramanh16/example-vote
59

Nhóm 4: Docker

3.3.2. Testing
Sau các bước cấu hình như trên, chúng tôi đã hoàn thành việc cài đặt cơ bản
để Gitlab có thể tự xử lý tác vụ test, build, push image.
Để xác nhận lại, chúng tôi sẽ tiến hành sửa mã nguồn và so sánh sự thay đổi.
Pipeline có thể được thực hiện thủ công bằng Run Pipeline.

Quá trình test, build sẽ được cập nhật liên tục.
60

Nhóm 4: Docker

Sau khi build thành công thì Image được push vào Docker Hub:

Tại node manager, sử dụng lệnh sau để tạo service, trong đó file
docker-stack.yml chứa thông tin cấu hình về các dịch vụ mà Swarm sẽ tạo.
1. root@hackerman # docker stack deploy -c docker-stack.yml voting
Thực hiện thay đổi trên branch master:

61

Nhóm 4: Docker

Pipeline tự động được tạo ra bao gồm 2 stage được định nghĩa:
Sau khi build thành công image example-vote chứa đoạn mã đã sửa đổi
được push lên Docker Hub.
Tuy nhiên code đang thực thi vẫn chưa được update. Để update code hiện
tại chỉ cần sử dụng lại lệnh:
1. root@hackerman # docker stack deploy -c docker-stack.yml voting

Theo dõi trong Portainer, có thể nhận ra container dùng image cũ đã được
thay bằng container sử dụng image mới.

Trang web bình chọn trước và sau khi thay đổi:
62

Nhóm 4: Docker

PART IV: APPENDIXES
1. Docker History
Công nghệ phát triển, hàng loạt các ứng dụng được tạo ra, nhiều ngôn ngữ
lập trình mới hình thành nhằm đáp ứng nhu cầu cụ thể nào đó. Những ngôn
ngữ lập trình khác nhau lại yêu cầu các phần mềm hỗ trợ, gói thư viện và
môi trường khác nhau. Ví dụ bạn là lập trình Android, bạn muốn làm việc với
IOS bạn phải cài thêm OS hoặc để deploy được các ứng dụng Python, Java,
Scala…. bạn phải tiến hành cài đặt hàng tá môi trường. Đó là chưa kể xung
đột phần mềm, port… Vì thế, trước nhu cầu sử dụng những công cụ và
service để người sử dụng có thể đóng gói và chạy chương trình của mình
trên các môi trường khác nhau một cách nhanh nhất, Docker ra đời như một
giải pháp vô cùng hữu ích.
Solomon Hykes bắt đầu tạo ra Docker khi làm việc ở Pháp, trong một dự án
nội bộ của dotCloud, một công ty nền tảng-như-dịch vụ, ban đầu có thêm sự
đóng góp của các kỹ sư dotCloud là Andrea Luzzardi và Francois-Xavier
Bourlet.Jeff Lindsay cũng đã tham gia như là một nhà cộng tác độc lập.
Docker được phát hành dạng mã nguồn mở trong tháng 3 năm 2013. Vào
ngày 13 năm 2014, với phiên bản 0.9, Docker bỏ đi LXC và thay thế nó với thư
viện của mình là libcontainer được viết bằng ngôn ngữ Go. Tới tháng 10 năm
2015, dự án Docker đã có hơn 25,600 sao trên GitHub (trở thành top 20 dự án
có số sao cao nhất trên GitHub), có hơn 6,800 fork, và gần 1.100 lập trình viên
tham gia đóng góp.
Tháng năm 2016, phân tích cho thấy các tổ chức sau có đóng góp chính cho
việc phát triển Docker: nhóm Docker, Cisco, Google, Huawei, IBM, Microsoft,
và Red Hat.
64

Nhóm 4: Docker

Hình 4.1.
2. CI/CD
2.1. CI
CI: Continuous Integration là quy trình build và test đơn giản cho một ứng
dụng.
Một kịch bản CI bắt đầu bằng việc developer commit code lên repository
(github chẳng hạn). Bất kỳ thay đổi nào cũng sẽ trigger một vòng đời CI. Các
bước trong một kịch bản CI thường như sau:
● Đầu tiên, developer commit code lên repository.
● Ngay sau đó, một trigger tới server được dùng để build thông báo
source code mới được thay đổi trong repo.
● Quá trình build bắt đầu trong một container được dựng sẵn (có thể
lấy container từ bất kỳ repo nào VD: docker hub) và chạy các câu lệnh
được developer xác định trước.
● CI server sẽ sinh ra log trong cả quá trình chạy, giúp dev có thể quan
sát và kiểm tra. Nếu lỗi, quá trình build sẽ bị dừng lại và code mới
không được deploy.
● CI server tiếp tục chờ thay đổi ở repo.
65

Nhóm 4: Docker

Hình 4.2. Hệ thống CI đơn giản.
2.2. CD
CD: Continuous Delivery là quá trình triển khai ứng dụng tự động vào hệ
thống sau quá trình build và test. Các câu lệnh cần thiết được xác định trước
và chạy theo thứ tự.
Khác với quy trình build và test, nếu quá trình deploy bị lỗi, ứng dụng sẽ
được rollback về phiên bản trước chứ không chỉ dừng lại và kết thúc.
Note: trong tình huống dựng hệ thống CI cho Cluster container (VD:
Kubernetes, Docker Swarm), người ta không thực hiện build và deploy lên
từng container mà sử dụng một container được cài sẵn docker trong đó và
thực hiện build cả image cho container, sau đó trigger đến cluster yêu cầu
update các container từ image mới. (xem thêm Reference [3])
3. Who uses Docker?
Docker ngày càng trở nên gần gũi với các startup cũng như với những tập
đoàn kinh tế lớn cho dù nó chỉ đang là một công cụ rất mới.
Tuy nhiên, theo báo cáo của Datadog, việc chuyển sang Docker thực sự đang
được dẫn dắt bởi các công ty lớn hơn (với 500 máy chủ trở lên), thay vì các
công ty startup nhỏ hơn.
● HBO (nền tảng phát trực tuyến)
○ Trước khi dùng Docker:
■ Được triển khai trên Amazon Web Services (AWS) và ban
đầu được xây dựng bằng các phiên bản EC2 virtual (máy
66

Nhóm 4: Docker

ảo của Amazon) , được thiết lập với khả năng tự động mở
rộng.
■ Thách thức xảy ra khi nhu cầu từ người xem tăng đột
biến, EC2 không đảm bảo được tốc độ scale cần thiết,
còn có thế hết các địa chỉ IP có sẵn để giúp cung cấp nội
dung cho người xem.
○ Sau khi dùng Docker:
■ Quyết định lựa chọn công nghệ Kubernetes.
■ Tốc độ scale tốt hơn giúp đáp ứng nhu cầu người xem
tăng đột xuất.
● Netflix
○ Trước khi dùng Docker:
■ Cơ sở hạ tầng được triển khai dựa trên máy ảo của
Amazon (EC2).
■ Gặp khó khăn trong việc tạo hàng loạt các môi trường
cho người dùng.
■ Có một số lượng đáng kể người dùng chạy công việc
theo thời gian, thời gian còn lại tài nguyên máy ảo bị lãng
phí, khởi động và tắt máy ảo cũng khá tốn thời gian, có
thể là hàng phút đến hàng chục phút.
○ Sau khi dùng Docker:
■ Với Docker image có thể tạo hàng loạt các môi trường
một cách nhanh chóng.
■ Các Container (Guess OS) sử dụng chung kernel và chia
sẻ tài nguyên của máy mẹ (Host OS) nên việc tận dụng
tài nguyên sẽ được tối ưu hơn, các thao tác bật, tắt cũng
rất nhẹ nhàng, nhanh chóng.
67

Nhóm 4: Docker

REFERENCE
Paper and Documentation
[1] Docker Reference Architecture: Design Scalable, Portable Docker
Container Networks
Mark Church, Technical Account Manager (San Francisco)
https://success.docker.com/article/networking

[2] Container-based Network Function Virtualization for Software-Defined
Networks
Richard Cziva, Simon Jouet, Kyle J. S. White and Dimitrios P. Pezaros School
of Computing Science, University of Glasgow, Glasgow, G12 8QQ, Scotland
ISCC 2015
http://richard.systems/research/pdf/IEEE_ISCC_GLANF.pdf

[3] Continuous Deployment to Kubernetes using AWS CodePipeline, AWS
CodeCommit, AWS CodeBuild, AWS ECR and AWS Lambda
Chris Barclay | on 11 JAN 2018 | in AWS CodeBuild, AWS CodeCommit, AWS
CodePipeline, Developer Tools | Permalink
https://aws.amazon.com/vi/blogs/devops/continuous-deployment-to-kubern
etes-using-aws-codepipeline-aws-codecommit-aws-codebuild-amazon-ecr-
and-aws-lambda

[4] Docker documentation
Docker, Inc
https://docs.docker.com/

[5] Kubernetes documentation
The Kubernetes Authors
https://kubernetes.io/docs/home/

68

Nhóm 4: Docker

Link and Website
[2.1] Shipping Manifests, Bill of Lading and Docker Metadata and Containers
https://www.youtube.com/watch?v=j4SZ1qoR8Hs&feature=youtu.be
[2.2] Docker Run
https://docs.docker.com/engine/reference/commandline/run/
[2.3] CI/CD và... DevOps
https://viblo.asia/p/ci-cd-va-devops-07LKXYXDZV4
[2.4] Docker Security
https://docs.docker.com/engine/security/security/
[2.5] Introduction to microservices
https://www.nginx.com/blog/introduction-to-microservices/
[2.6] Introduction to microservices (bản dịch)
https://techmaster.vn/posts/33594/gioi-thieu-ve-microservices
[2.7] Những điều cơ bản về sandbox
https://viblo.asia/p/nhung-dieu-co-ban-ve-sandbox-gDVK28MXlLj
[2.8] Sandbox là gì và cách sử dụng
https://quantrimang.com/sandboxing-la-gi-va-cach-sandbox-mot-chuong-tr
inh-nhu-the-nao-156048
[2.9] Tài liệu API của Kubernetes
https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.14/
69

Docker 101

More Related Content

What's hot (20)

Similar to Docker 101 (20)

Recently uploaded (20)

Docker 101