Giờ là 3 giờ sáng, thật ra đầu óc mình tầm này chắc không ổn lắm, nhưng mà ngủ không được nên viết tiếp. Dù sao thì mấy cái này viết cũng vui. Bắt đầu thế nào nhỉ. Thôi thì góc nhìn về container trong phần này đi. Cái gì cũng vậy, từ đặc tính sinh ra cách sử dụng mà cách sử dụng thì có ưu có nhược, việc container được áp dụng cũng thế. Nó đã sinh ra rất nhiều thứ và định hình ra cung cách sử dụng của chúng ta với container.
So với máy ảo thì container nhanh hơn rất nhiều, nhẹ hơn, khởi động hay xoá bỏ đều rất ưu việt, điểm này đã được đẩy lên tận cùng bằng nhiều cách để rồi container trở thành một loại cấu trúc mà khi nhìn vào nó ta thấy sự tuỳ biến cao, scale dễ dàng, động và thêm một thứ nữa đó là tính không bền. Chúng ta dễ dàng làm mới hay xoá bỏ đồng nghĩa với việc những thứ chạy bằng container rất dễ mất nếu không quản lý đúng cách.
Điều này dẫn tới việc để thật sự áp dụng container vào môi trường production chúng ta phải biết tách biệt các phần mà dữ liệu của nó không được phép biến mất, trong một hệ thống db chẳng hạn bạn sẽ phải tìm hiểu xem file nào thật sự là khu vực lưu trữ thay đổi dữ liệu db. Hay đơn giản trong một hệ thống file code bạn sẽ cố định những phần liên quan tới file định nghĩa môi trương (.env) hoặc logs. Điều này sẽ giúp việc khi chúng ta sửa đổi thông tin container hay update nó những phần dữ liệu chính vẫn tồn tại và được sử dụng đi sử dụng lại không biến mất khi sự cố sảy ra. Thứ này hiểu là persistent storage hay đưoợc gọi dưới tên volume.
Container thật sự hoạt động ra sao, nó lưu trữ ở đâu và thứ gì đã tạo nên container. Đây là điều mà mình cho là cần thiết để hiểu một hệ thống. Chứ nếu cứ vứt cho mọi người một cái hướng dẫn sử dụng thì ok thôi, nhưng rồi đào tạo ra một lũ ngơ cả.
Container là một ý tưởng với rất nhiều đầu tư về công sức. Ai cũng nghe về việc Container chạy chung nhân rồi, nhưng mà chạy chung nhân thế nào? .
Linux sau một thời gian dài đã đẩn ra 2 thứ Cgroup và Namespace.
X) Cgroup (Control Groups) quản lý các nhóm con hay nói trắng ra là bạn có khả năng tạo các group với giới hạn khả năng sử dụng nền tảng phần cứng của máy. Thứ này tất nhiên là không phải nhân kernel mà là một tính năng hỗ trợ cho user space để chúng ta có thể phân cấp cũng như cấp phát phần cứng. Mỗi process trong docker bạn đều có thể view nó dưới dạng máy host.
systemd-cgls
Đây là các process trong các container của mình. Đại khái bạn hiểu cgroup là về phần cứng, cấp phát đo lường và giới hạn tài nguyên.
X) Namespace sẽ tách biệt khả năng view dựa theo UID, và quan trọng nhất là việc tạo ra network để biến các container có thể truy cập hay tạo ra môi trường microservices thật sự. Từ khoá để xem một hệ thống mạng của container trong linux tạo ra sao các bạn có thể search “Network Namespace” hay cao hơn là CNI để nhìn tổng quan các hệ thống quản trị container orchestration.
Mấy thứ trên là những thứ bạn cần tư duy trước khi tìm hiểu và sử dụng container. Giờ chúng ta sẽ cùng sử dụng container. Một container đơn giản. Đoạn này chú tâm chút, vì demo thì ít nhưng mình giải thích sẽ là phần nhiều.
Đầu tiên mình sẽ chạy một container centos.
Tiếp theo chúng ta sẽ kiểm tra xem container centos đã được chạy hay chưa.
Rồi trống trỗng, khi chạy lệnh “docker ps“. docker ps trả về các container đang chạy. Giờ chúng ta sẽ chạy “docker ps -a” để hiển thị tất cả các container cả những container đã stop.
Và đây, nó đây rồi, container centos của chúng ta. Câu hỏi là tại sao chúng ta chạy một image nhưng sau đó nó dừng ngay lập tức?
Docker luôn cần lệnh của bạn hay nói cách khác là một process để nhận biết bản thân cần phải chạy, do đó nếu process kết thúc container sẽ ngay lập tức stop và tạm dừng container. Vậy để giải quyết vấn đề này nếu container là do bạn tự xây dựng bạn phải khởi chạy nó từ ngay giai đoạn bắt đầu container. Ví dụ
docker exec -i -t centos /đường_dẫn_app Và như thế thì container của bạn sẽ chạy.
Ok đây là một ví dụ về việc container thật sự đã chạy nhưng ngay sau đó kết thúc vì lệnh done. Mình đã run image centos dùng sh để in ra a và b. Tất nhiên là sau đó container stop vì lệnh này không loop.
Rồi liệt kê lại các thứ. Bây giờ chúng ta có thể phân tích lệnh run đầu tiên rồi.
-i : STDIN, bạn mở đường nhập liệu vào dưới dạng terminal.
-t : tạo tty hay nói cách khác là terminal cho container.
sh -c “echo a && echo b” : chạy sh (hoặc bash tuỳ), truyền vào string lệnh. Chắc tới đây rối não nhỉ. Thôi rồi cứ định hình là như vậy là chúng ta đã có thể tương tác với một trường hợp container khó. Việc contaier tự out với các ứng dụng thì thường không sảy ra vì bản thân khi các hãng xây ra container riêng mình thì họ luôn tạo process giưx container chạy. Vấn đề trên để làm nền cho việc bạn tự build một container của mình và hiểu container sẽ chạy ra sao.
đây là một phần của đống container mình đang chạy.
Vậy thì làm sao để tương tác với một container. Đơn giản là chúng ta dùng câu lệnh “docker exec”
Truy cập vào một container bằng bash. Khi vào tới đây các bạn tương tác như việc can thiệp vào một máy ảo linux bình thường. Tiện thể thì mình không dậy linux, nên là mò đi.
Trò trẻ con. Để đọc logs mà debug thì các bạn dùng cho mình lệnh “docker logs”
log đơn giản của một image nginx. Đúng rồi, trèo vào tới đây rồi thì chịu khó mà lần mò đọc logs debug =)) không ai dạy debug đâu.
…………..
Đấy, cái lệnh chính để tương tác với cái container nhỏ nhoi của bạn chỉ có từng đấy, vì mình lọc hết phần network rồi. Trên đây chỉ là cách truy xuất theo dõi và tự tìm hiểu bug thôi. Thân làm devop thì đừng mong có tool debug như các bạn dev ngôn ngữ may mắn, tự tưởng tượng luồng hệ thống nhá bạn nhỏ.
