Bước đầu tiên khi triển khai Kubernetes là đặt ứng dụng của bạn vào một vùng chứa. Trong loạt bài này, chúng ta sẽ xem xét cách bạn có thể tạo một hình ảnh vùng chứa nhỏ, an toàn.
Nhờ Docker, việc tạo hình ảnh vùng chứa chưa bao giờ dễ dàng hơn thế. Chỉ định hình ảnh cơ sở, thêm các thay đổi của bạn và tạo vùng chứa.
Mặc dù kỹ thuật này rất tốt để bắt đầu nhưng việc sử dụng hình ảnh cơ sở mặc định có thể dẫn đến công việc không an toàn với hình ảnh lớn chứa đầy lỗ hổng.
Ngoài ra, hầu hết hình ảnh trong Docker đều sử dụng Debian hoặc Ubuntu cho hình ảnh cơ sở và mặc dù điều này mang lại khả năng tương thích tuyệt vời và tùy chỉnh dễ dàng (tệp Docker chỉ mất hai dòng mã), hình ảnh cơ sở có thể tăng thêm hàng trăm megabyte tải vào vùng chứa của bạn. Ví dụ: một tệp node.js đơn giản cho ứng dụng Go "hello-world" có dung lượng khoảng 700 megabyte, trong khi ứng dụng thực tế của bạn chỉ có kích thước vài megabyte.
Vì vậy, tất cả khối lượng công việc tăng thêm này là sự lãng phí không gian kỹ thuật số và là nơi ẩn náu tuyệt vời cho các lỗ hổng và lỗi bảo mật. Vì vậy, hãy xem xét hai cách để giảm kích thước của hình ảnh vùng chứa.
Đầu tiên là sử dụng các hình ảnh cơ sở nhỏ, thứ hai là sử dụng Mẫu xây dựng. Sử dụng hình ảnh cơ sở nhỏ hơn có lẽ là cách dễ nhất để giảm kích thước vùng chứa của bạn. Rất có thể, ngôn ngữ hoặc ngăn xếp bạn đang sử dụng cung cấp hình ảnh ứng dụng gốc nhỏ hơn nhiều so với hình ảnh mặc định. Chúng ta hãy xem vùng chứa node.js của chúng tôi.
Theo mặc định trong Docker, kích thước hình ảnh cơ sở của nút: 8 là 670 MB và kích thước hình ảnh của nút: 8-alpine chỉ là 65 MB, tức là nhỏ hơn 10 lần. Bằng cách sử dụng hình ảnh cơ sở Alpine nhỏ hơn, bạn sẽ giảm đáng kể kích thước vùng chứa của mình. Alpine là một bản phân phối Linux nhỏ và nhẹ rất phổ biến đối với người dùng Docker vì nó tương thích với nhiều ứng dụng trong khi vẫn giữ kích thước nhỏ cho các thùng chứa. Không giống như hình ảnh "nút" Docker tiêu chuẩn, "node:alpine" loại bỏ rất nhiều tệp và chương trình dịch vụ, chỉ để lại những tệp đủ để chạy ứng dụng của bạn.
Để chuyển sang hình ảnh cơ sở nhỏ hơn, chỉ cần cập nhật Dockerfile để bắt đầu làm việc với hình ảnh cơ sở mới:
Bây giờ, không giống như hình ảnh onbuild cũ, bạn cần sao chép mã của mình vào vùng chứa và cài đặt mọi phần phụ thuộc. Trong Dockerfile mới, vùng chứa bắt đầu bằng hình ảnh node:alpine, sau đó tạo thư mục cho mã, cài đặt các phần phụ thuộc bằng trình quản lý gói NPM và cuối cùng chạy server.js.
Việc nâng cấp này dẫn đến một thùng chứa có kích thước nhỏ hơn 10 lần. Nếu ngôn ngữ lập trình hoặc ngăn xếp của bạn không có chức năng giảm hình ảnh cơ bản, hãy sử dụng Alpine Linux. Nó cũng sẽ cung cấp khả năng quản lý đầy đủ nội dung của vùng chứa. Sử dụng hình ảnh cơ sở nhỏ là cách tuyệt vời để nhanh chóng tạo các vùng chứa nhỏ. Nhưng thậm chí có thể đạt được mức giảm lớn hơn bằng cách sử dụng Mẫu xây dựng.
Trong các ngôn ngữ được thông dịch, mã nguồn trước tiên được chuyển tới trình thông dịch và sau đó được thực thi trực tiếp. Trong các ngôn ngữ được biên dịch, mã nguồn trước tiên được chuyển đổi thành mã được biên dịch. Tuy nhiên, quá trình biên dịch thường sử dụng các công cụ không thực sự cần thiết để chạy mã. Điều này có nghĩa là bạn có thể loại bỏ hoàn toàn các công cụ này khỏi vùng chứa cuối cùng. Bạn có thể sử dụng Mẫu Builder cho việc này.
Mã được tạo trong vùng chứa đầu tiên và được biên dịch. Mã đã biên dịch sau đó được đóng gói vào vùng chứa cuối cùng mà không có trình biên dịch và công cụ cần thiết để biên dịch mã đó. Hãy chạy ứng dụng Go thông qua quá trình này. Đầu tiên, chúng ta sẽ chuyển từ image onbuild sang Alpine Linux.
Trong Dockerfile mới, vùng chứa bắt đầu bằng hình ảnh golang:alpine. Sau đó, nó tạo một thư mục chứa mã, sao chép mã đó vào mã nguồn, xây dựng mã nguồn đó và chạy ứng dụng. Vùng chứa này nhỏ hơn nhiều so với vùng chứa onbuild, nhưng nó vẫn chứa trình biên dịch và các công cụ Go khác mà chúng ta không thực sự cần. Vì vậy, hãy giải nén chương trình đã biên dịch và đặt nó vào vùng chứa riêng của nó.
Bạn có thể nhận thấy điều gì đó kỳ lạ trong tệp Docker này: nó chứa hai dòng TỪ. Phần 4 dòng đầu tiên trông giống hệt như Dockerfile trước ngoại trừ việc nó sử dụng từ khóa AS để đặt tên cho giai đoạn này. Phần tiếp theo có một dòng FROM mới để bắt đầu một hình ảnh mới, trong đó thay vì hình ảnh golang:alpine, chúng ta sẽ sử dụng Raw Alpine làm hình ảnh cơ sở.
Alpine Linux thô chưa cài đặt bất kỳ chứng chỉ SSL nào, điều này sẽ khiến hầu hết các lệnh gọi API qua HTTPS không thành công, vì vậy hãy cài đặt một số chứng chỉ CA gốc.
Bây giờ đến phần thú vị: để sao chép mã đã biên dịch từ vùng chứa đầu tiên sang vùng chứa thứ hai, bạn chỉ cần sử dụng lệnh COPY nằm ở dòng 5 của phần thứ hai. Nó sẽ chỉ sao chép một tệp ứng dụng và không ảnh hưởng đến các công cụ tiện ích Go. Tệp Docker nhiều giai đoạn mới sẽ chứa hình ảnh vùng chứa có kích thước chỉ 12 megabyte, so với hình ảnh vùng chứa ban đầu là 700 megabyte, đây là một sự khác biệt lớn!
Vì vậy, sử dụng hình ảnh cơ sở nhỏ và Mẫu xây dựng là những cách tuyệt vời để tạo các vùng chứa nhỏ hơn nhiều mà không cần tốn nhiều công sức.
Có thể tùy thuộc vào ngăn xếp ứng dụng, có những cách bổ sung để giảm kích thước hình ảnh và vùng chứa, nhưng các vùng chứa nhỏ có thực sự mang lại lợi ích có thể đo lường được không? Hãy xem xét hai lĩnh vực mà các thùng chứa nhỏ cực kỳ hiệu quả - hiệu suất và bảo mật.
Để đánh giá mức tăng hiệu suất, hãy xem xét khoảng thời gian của quá trình tạo vùng chứa, chèn nó vào sổ đăng ký (đẩy) rồi truy xuất nó từ đó (kéo). Bạn có thể thấy rằng thùng chứa nhỏ hơn có lợi thế khác biệt so với thùng chứa lớn hơn.
Docker sẽ lưu trữ các lớp nên các bản dựng tiếp theo sẽ rất nhanh. Tuy nhiên, nhiều hệ thống CI được sử dụng để xây dựng và thử nghiệm vùng chứa không lưu các lớp vào bộ đệm, do đó tiết kiệm đáng kể thời gian. Như bạn có thể thấy, thời gian để xây dựng một thùng chứa lớn, tùy thuộc vào công suất máy của bạn, là từ 34 đến 54 giây và khi sử dụng một thùng chứa giảm bằng cách sử dụng Mẫu xây dựng - từ 23 xuống 28 giây. Đối với các hoạt động kiểu này, năng suất tăng sẽ là 40-50%. Vì vậy, hãy nghĩ xem bạn xây dựng và kiểm tra mã của mình bao nhiêu lần.
Sau khi vùng chứa được tạo, bạn cần đẩy hình ảnh của nó (đẩy hình ảnh vùng chứa) vào sổ đăng ký vùng chứa để sau đó bạn có thể sử dụng nó trong cụm Kubernetes của mình. Tôi khuyên bạn nên sử dụng Google Container Đăng ký.
Với Google Container Đăng ký (GCR), bạn chỉ trả tiền cho dung lượng lưu trữ thô và kết nối mạng, đồng thời không phải trả thêm phí quản lý vùng chứa. Nó riêng tư, an toàn và rất nhanh chóng. GCR sử dụng nhiều thủ thuật để tăng tốc thao tác kéo. Như bạn có thể thấy, việc chèn một Docker Container Image container bằng go:onbuild sẽ mất từ 15 đến 48 giây, tùy thuộc vào hiệu suất của máy tính và thao tác tương tự với một container nhỏ hơn sẽ mất từ 14 đến 16 giây và đối với các máy kém năng suất hơn lợi thế về tốc độ hoạt động tăng gấp 3 lần. Đối với các máy lớn hơn, thời gian là như nhau, vì GCR sử dụng bộ đệm chung cho cơ sở dữ liệu hình ảnh được chia sẻ, nghĩa là bạn hoàn toàn không cần tải chúng. Ở một máy tính có công suất thấp, CPU là điểm nghẽn cổ chai nên lợi ích của việc sử dụng các thùng chứa nhỏ ở đây lớn hơn rất nhiều.
Nếu bạn đang sử dụng GCR, tôi khuyên bạn nên sử dụng Google Container Builder (GCB) như một phần của hệ thống xây dựng của mình.
Như bạn có thể thấy, việc sử dụng nó cho phép bạn đạt được kết quả tốt hơn nhiều trong việc giảm thời gian của thao tác Build+Push so với cả một máy hiệu quả - trong trường hợp này, quá trình xây dựng và gửi vùng chứa đến máy chủ được tăng tốc gần gấp 2 lần . Ngoài ra, bạn nhận được 120 phút xây dựng miễn phí mỗi ngày, đáp ứng nhu cầu xây dựng container của bạn trong hầu hết các trường hợp.
Tiếp theo là chỉ số hiệu suất quan trọng nhất – tốc độ truy xuất hoặc tải xuống vùng chứa Kéo. Và nếu bạn không quan tâm nhiều đến thời gian dành cho thao tác đẩy thì độ dài của quá trình kéo sẽ có tác động nghiêm trọng đến hiệu suất tổng thể của hệ thống. Giả sử bạn có một cụm gồm ba nút và một trong số chúng bị lỗi. Nếu bạn đang sử dụng hệ thống quản lý như Google Kubernetes Engine, nó sẽ tự động thay thế nút chết bằng một nút mới. Tuy nhiên, nút mới này sẽ hoàn toàn trống và bạn sẽ phải kéo tất cả các vùng chứa của mình vào đó để nó bắt đầu hoạt động. Nếu thao tác kéo mất đủ thời gian, cụm của bạn sẽ chạy với hiệu suất thấp hơn trong toàn bộ thời gian.
Có nhiều trường hợp điều này có thể xảy ra: thêm nút mới vào cụm, nâng cấp nút hoặc thậm chí chuyển sang vùng chứa mới để triển khai. Vì vậy, giảm thiểu thời gian kéo kéo trở thành một yếu tố quan trọng. Không thể phủ nhận rằng thùng nhỏ tải xuống nhanh hơn nhiều so với thùng lớn. Nếu bạn đang chạy nhiều container trong cụm Kubernetes, mức tiết kiệm thời gian có thể rất đáng kể.
Hãy xem so sánh này: thao tác kéo trên các thùng chứa nhỏ mất ít thời gian hơn 4-9 lần, tùy thuộc vào công suất của máy, so với thao tác tương tự bằng cách sử dụng go:onbuild. Việc sử dụng các hình ảnh cơ sở vùng chứa nhỏ, được chia sẻ sẽ tăng tốc đáng kể thời gian và tốc độ mà các nút Kubernetes mới có thể được triển khai và trực tuyến.
Hãy nhìn vào vấn đề bảo mật. Các thùng chứa nhỏ hơn được coi là an toàn hơn nhiều so với các thùng chứa lớn hơn vì chúng có bề mặt tấn công nhỏ hơn. Có thực sự vậy không? Một trong những tính năng hữu ích nhất của Google Container Register là khả năng tự động quét các vùng chứa của bạn để tìm lỗ hổng. Một vài tháng trước, tôi đã tạo cả vùng chứa onbuild và multistage, vì vậy hãy xem liệu có bất kỳ lỗ hổng nào ở đó không.
Kết quả thật đáng kinh ngạc: chỉ phát hiện được 3 lỗ hổng trung bình trong một thùng chứa nhỏ, 16 lỗ hổng nghiêm trọng và 376 lỗ hổng khác được tìm thấy trong một thùng chứa lớn. Nếu nhìn vào nội dung của một thùng chứa lớn, chúng ta có thể thấy rằng hầu hết các vấn đề bảo mật không liên quan gì đến ứng dụng của chúng ta mà liên quan đến các chương trình mà chúng ta thậm chí không sử dụng. Vì vậy, khi mọi người nói về một bề mặt tấn công lớn, đó chính là ý của họ.
Bài học rút ra rất rõ ràng: xây dựng các thùng chứa nhỏ vì chúng mang lại lợi ích bảo mật và hiệu suất thực sự cho hệ thống của bạn.
Một số quảng cáo 🙂
Cảm ơn bạn đã ở với chúng tôi. Bạn có thích bài viết của chúng tôi? Bạn muốn xem nội dung thú vị hơn? Hỗ trợ chúng tôi bằng cách đặt hàng hoặc giới thiệu cho bạn bè, , một dạng tương tự duy nhất của các máy chủ cấp đầu vào do chúng tôi phát minh ra dành cho bạn: (có sẵn với RAID1 và RAID10, tối đa 24 lõi và tối đa 40GB DDR4).
Dell R730xd rẻ hơn gấp 2 lần tại trung tâm dữ liệu Equinix Tier IV ở Amsterdam? Chỉ ở đây ở Hà Lan! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - từ $99! Đọc về
Nguồn: www.habr.com