Triển khai Sổ đăng ký vùng chứa Docker tự lưu trữ trên Azure Stack Hub

Giới thiệu

Chào mừng bạn đến với Phần 3 của loạt blog gồm ba phần về việc chạy các ứng dụng được đóng gói trên hệ sinh thái kết hợp của Microsoft Azure. Trong phần này, chúng ta sẽ tìm hiểu cách triển khai Docker Register v2 mã nguồn mở, tự lưu trữ cho đăng ký người dùng Azure Stack Hub. Chúng tôi cũng thảo luận về cách chúng tôi đẩy một ứng dụng dựa trên vi dịch vụ sang sổ đăng ký tự lưu trữ, sau đó kéo những hình ảnh đó từ sổ đăng ký đó vào cụm K8 mà chúng tôi đã triển khai bằng công cụ AKS.   

Dưới đây là sơ đồ mô tả kiến ​​trúc cấp cao trong phòng thí nghiệm để xem xét.

Có một số lý do khiến một tổ chức có thể muốn triển khai và duy trì sổ đăng ký vùng chứa tại chỗ thay vì tận dụng sổ đăng ký có thể truy cập công khai như Docker Hub. Cách tiếp cận này có thể đặc biệt hấp dẫn đối với khách hàng trong các triển khai air-gapped nơi có kết nối không đáng tin cậy với Public Azure hoặc hoàn toàn không có kết nối. Điều này có thể hoạt động tốt với các cụm K8 đã được triển khai bằng công cụ AKS tại các cơ sở quân sự hoặc các địa điểm khác. Cũng có thể có các vấn đề về tuân thủ quy định, chủ quyền dữ liệu hoặc trọng lực dữ liệu có thể được giải quyết bằng cơ quan đăng ký vùng chứa địa phương. Một số khách hàng có thể chỉ yêu cầu kiểm soát chặt chẽ hơn nơi hình ảnh của họ được lưu trữ hoặc cần tích hợp chặt chẽ việc lưu trữ và phân phối hình ảnh vào quy trình phát triển nội bộ của họ.

Điều kiện tiên quyết

Việc triển khai Docker Đăng ký v2 vào đăng ký người dùng Azure Stack Hub được thực hiện bằng cách sử dụng  mẫu 101-vm-linux-docker-registry Azure Stack Hub QuickStart . Có hai giai đoạn để triển khai này:

1. Tạo tài khoản lưu trữ và kho khóa trong một nhóm tài nguyên riêng biệt bằng cách chạy  tập lệnh setup.ps1  PowerShell được cung cấp trong kho lưu trữ mẫu.

2.  Tập lệnh setup.ps1  cũng đã tạo  tệp azuredeploy.parameters.json  được sử dụng trong lệnh PowerShell để triển khai mẫu ARM mô tả máy ảo đăng ký vùng chứa và các tài nguyên liên quan của nó. Những tài nguyên này được cung cấp vào một nhóm tài nguyên riêng biệt.

Xin lưu ý rằng có một kho lưu trữ thử nghiệm khác trong GitHub có tên là  msazurestackworkloads  để triển khai Docker Register. Sự khác biệt chính là mã trong  kho lưu trữ msazurestackworkloads  bao gồm các thành phần lạ để tạo mục thư viện thị trường mà người dùng Azure Stack Hub có thể triển khai vào đăng ký của họ. Một lần nữa, đây hiện đang là thử nghiệm và không được hỗ trợ để triển khai Docker Register.

Một trong những bước tiên quyết là lấy chứng chỉ SSL X.509 ở định dạng PFX để tải vào kho khóa. Chúng tôi đã chỉ ra vị trí của nó trong quá trình chạy thiết  lập . kịch bản ps1  . Chúng tôi đã sử dụng CA độc lập nội bộ của phòng thí nghiệm của mình để tạo chứng chỉ, chính là CA được sử dụng để triển khai cụm K8 với công cụ AKS. Chúng tôi nghĩ rằng chúng tôi sẽ chia sẻ các bước chúng tôi đã thực hiện để có được chứng chỉ này trong trường hợp bất kỳ độc giả nào chưa quen với quy trình này. Tất cả các bước này phải được hoàn thành từ cùng một máy trạm để đảm bảo quyền truy cập vào khóa riêng.

Chúng tôi đã thực hiện các bước sau trên máy trạm quản lý:

1. Tạo một tệp INF có dạng như sau. CN của chủ thể là tên DNS mà chúng tôi đã cung cấp cho địa chỉ IP công cộng của máy ảo đăng ký.

[Phiên bản]

Chữ ký=”$Windows NT$”

[Yêu cầu mới]

Chủ đề = “CN=cseregistry.rack04.cloudapp.azs.mhclabs.com,O=CSE Lab,L=Round Rock,S=Texas,C=US”

Có thể xuất = TRUE

Độ dài khóa = 2048

Thông số khóa = 1

Sử dụng khóa = 0xA0

MachineKeySet = Đúng

ProviderName = “Nhà cung cấp mật mã Microsoft RSA SChannel”

Thuật toán băm = SHA256

Loại yêu cầu = PKCS10

[Dây]

szOID_SUBJECT_ALT_NAME2 = “2.5.29.17”

szOID_ENHANCED_KEY_USAGE = “2.5.29.37”

szOID_PKIX_KP_SERVER_AUTH = “1.3.6.1.5.5.7.3.1”

szOID_PKIX_KP_CLIENT_AUTH = “1.3.6.1.5.5.7.3.2”

[Tiện ích mở rộng]

%szOID_SUBJECT_ALT_NAME2% = “{text}dns=cseregistry.rack04.cloudapp.azs.mhclabs.com”

%szOID_ENHANCED_KEY_USAGE% = “{text}%szOID_PKIX_KP_SERVER_AUTH%,%szOID_PKIX_KP_CLIENT_AUTH%”

[Thuộc tính yêu cầu]  

2. Chúng tôi đã sử dụng lệnh certreq.exe để tạo CSR mà sau đó tôi đã gửi cho CA.

certreq.exe – cseregistry_req.inf mới cseregistry_csr.req

3. Chúng tôi đã nhận được tệp .cer từ CA độc lập và làm theo hướng dẫn tại đây để chuyển đổi tệp .cer này thành tệp .pfx để sử dụng với sổ đăng ký vùng chứa.

 Chuẩn bị chứng chỉ PKI Azure Stack để triển khai hoặc luân chuyển

Chúng tôi cũng cần có chứng chỉ gốc của CA ở định dạng tệp .crt. Ban đầu chúng tôi có được điều này trong quá trình triển khai cụm K8 bằng công cụ AKS. Điều này cần được nhập vào kho chứng chỉ của bất kỳ thiết bị nào có ý định tương tác với cơ quan đăng ký vùng chứa.

Triển khai hạ tầng hỗ trợ đăng ký container

Chúng tôi đã sử dụng  tập lệnh PowerShell setup.ps1  có trong kho GitHub của mẫu QuickStart để tạo cơ sở hạ tầng hỗ trợ cho sổ đăng ký vùng chứa. Chúng tôi đặt tên cho nhóm tài nguyên mới được tạo bởi tập lệnh này  demoregistryinfra-rg . Nhóm tài nguyên này chứa tài khoản lưu trữ và kho khóa. Sổ đăng ký được cấu hình để sử dụng trình điều khiển lưu trữ Azure nhằm duy trì hình ảnh vùng chứa trong vùng chứa blob tài khoản lưu trữ. Kho khóa lưu trữ thông tin xác thực cần thiết để xác thực với cơ quan đăng ký dưới dạng bí mật và bảo mật chứng chỉ. Dịch vụ chính (SPN) được tạo trước khi  thực thi  tập lệnh setup.ps1  được tận dụng để truy cập vào tài khoản lưu trữ và kho khóa.

Dưới đây là các giá trị chúng tôi đã sử dụng cho các biến trong tập lệnh setup.ps1 để tham khảo (tất nhiên là đã xóa thông tin nhạy cảm). Lưu ý rằng giá trị $dnsLabelName chỉ là tên máy chủ của máy chủ đăng ký vùng chứa chứ không phải tên miền đủ điều kiện.

$location = “rack04”
$resourceGroup = “registryinfra-rg”
$saName = “registrystorage”
$saContainer = “hình ảnh”

$kvName = “registrykv”
$pfxSecret = “registrypfxsecret”
$pfxPath = “D:\ file_system_path \cseregistry.pfx”
$pfxPass = ” mypassword “
$spnName = ” ID ứng dụng (khách hàng) “
$spnSecret = ” Bí mật “
$userName = “cseadmin”
$userPass = “!!123abc”

$dnsLabelName = “cseregistry”
$sshKey = ” Khóa SSH được tạo bởi PuttyGen “
$vmSize = “Standard_F8s_v2”
$registryTag = “2.7.1”
$registryReplicas = “5”

Triển khai sổ đăng ký vùng chứa bằng mẫu QuickStart

Chúng tôi đã triển khai mẫu QuickStart bằng lệnh PowerShell tương tự như lệnh được chỉ ra trong README.md của kho lưu trữ GitHub. Một lần nữa, tệp azuredeploy.parameters.json được tạo tự động bởi tập lệnh setup.ps1. Điều này rất đơn giản. Điều duy nhất cần đề cập là chúng tôi đã tạo một nhóm tài nguyên mới khi triển khai mẫu QuickStart. Chúng tôi cũng có thể chọn một nhóm tài nguyên hiện có không chứa bất kỳ tài nguyên nào.

Kiểm tra Docker Đăng ký bằng ứng dụng Trình phân tích tình cảm

Tại thời điểm này, đã đến lúc kiểm tra cụm K8 và sổ đăng ký vùng chứa tự lưu trữ chạy trên Azure Stack Hub từ đầu đến cuối. Để làm được điều này, chúng tôi đã theo dõi một bài viết blog xuất sắc có tựa đề  Tìm hiểu Kubernetes trong vòng chưa đầy 3 giờ: Hướng dẫn chi tiết về điều phối các vùng chứa  được viết bởi Rinor Maloku. Đây là phần giới thiệu hoàn hảo về thế giới tạo ứng dụng dựa trên vi dịch vụ chạy trong nhiều vùng chứa. Nó bao gồm các nguyên tắc cơ bản của Docker và Kubernetes, đồng thời là tài liệu nền tảng tuyệt vời cho bất kỳ ai mới bắt đầu làm quen với thế giới container và điều phối container. Tên của ứng dụng là Trình phân tích tình cảm và nó sử dụng phân tích văn bản để xác định cảm xúc của câu.

Tìm hiểu Kubernetes trong vòng chưa đầy 3 giờ: Hướng dẫn chi tiết về sắp xếp các vùng chứa

Chúng tôi sẽ không chia sẻ tất cả những ghi chú mà chúng tôi đã ghi lại khi xem qua bài viết. Tuy nhiên, có một số mẹo mà chúng tôi muốn nêu bật khi chúng liên quan đến việc kiểm tra cụm K8 và Sổ đăng ký Docker tự lưu trữ mới trong phòng thí nghiệm:

• Điều đầu tiên chúng tôi làm để chuẩn bị tạo ứng dụng Trình phân tích tình cảm là thiết lập máy ảo Ubuntu 18.04 phát triển trong một nhóm tài nguyên duy nhất trong đăng ký người dùng trong phòng thí nghiệm của chúng tôi trên Azure Stack Hub. Chúng tôi đã cài đặt Firefox trên VM và Xming trên máy trạm quản lý để có thể kiểm tra chức năng của ứng dụng tại các điểm cần thiết trong quy trình. Sau đó, vấn đề chỉ là thiết lập PuTTY đúng cách với chuyển tiếp X11.
• Trước khi cài đặt bất kỳ thứ gì khác trên VM, chúng tôi đã nhập chứng chỉ gốc từ CA độc lập trong phòng thí nghiệm của chúng tôi. Điều này rất quan trọng để tạo điều kiện thuận lợi cho kết nối an toàn giữa máy ảo này và máy ảo đăng ký khi chúng tôi bắt đầu đẩy hình ảnh.
•  Bất cứ khi nào bài viết của Rinor nói về việc đẩy hình ảnh vùng chứa lên Docker Hub, thay vào đó, chúng tôi nhắm mục tiêu vào sổ đăng ký tự lưu trữ chạy trên Azure Stack Hub. Chúng tôi đã phải thực hiện các bước sau trên VM phát triển để tạo điều kiện thuận lợi cho các thủ tục đó:

• Đăng nhập vào sổ đăng ký vùng chứa bằng thông tin xác thực mà chúng tôi đã chỉ định trong  tập lệnh setup.ps1  .
• Đã gắn thẻ hình ảnh để nhắm mục tiêu đăng ký vùng chứa.

                  thẻ docker sudo <ID hình ảnh> cseregistry.rack04.cloudapp.azs.mhclabs.com/sentiment-analysis-frontend

• Đã đẩy hình ảnh vào sổ đăng ký vùng chứa.

            sudo docker đẩy cseregistry.rack04.cloudapp.azs.mhclabs.com/sentiment-analysis-frontend

• Sau khi hình ảnh được đẩy vào sổ đăng ký, chúng tôi phát hiện ra rằng chúng tôi có thể xem chúng từ máy trạm quản lý bằng cách duyệt đến URL sau và xác thực với sổ đăng ký:

           https://cseregistry.rack04.cloudapp.azs.mhclabs.com/v2/_catalog 

Đầu ra sau đây được đưa ra sau khi chúng tôi đẩy tất cả các hình ảnh ứng dụng:

{“kho lưu trữ”:[“sentiment-analysis-frontend”,”sentiment-analysis-logic”,”sentiment-analysis-web-app”]}

• Chúng tôi nhận thấy rằng chúng tôi không phải nhập chứng chỉ gốc của CA độc lập của phòng thí nghiệm trên nút chính trước khi thử lấy hình ảnh từ sổ đăng ký vùng chứa. Chúng tôi giả định rằng cụm đã lấy chứng chỉ gốc từ hệ thống Azure Stack Hub vì có một tệp có tên  /etc/ssl/certs/azsCertificate.pem  trên nút chính nơi chúng tôi đang chạy  kubectl . 
• Trước khi cố gắng tạo nhóm K8 cho giao diện Trình phân tích tình cảm, chúng tôi phải tạo một bí mật cụm Kubernetes. Điều này luôn cần thiết khi lấy hình ảnh từ kho lưu trữ riêng tư – cho dù chúng là kho lưu trữ riêng tư trên Docker Hub hay được lưu trữ riêng tại chỗ bằng cách sử dụng sổ đăng ký vùng chứa tự lưu trữ. Chúng tôi đã làm theo hướng dẫn ở đây để tạo bí mật: 

Kéo hình ảnh từ sổ đăng ký riêng tư

Trong phần của bài viết này có tựa đề  Tạo bí mật bằng cách cung cấp thông tin xác thực trên dòng lệnh , chúng tôi đã phát hiện ra một số mục cần lưu ý:

• Khi ban hành  lệnh kubectl create bí mật docker-registry  , chúng tôi phải đặt mật khẩu trong dấu ngoặc đơn vì đây là mật khẩu phức tạp.

  kubectl tạo bí mật docker-registry regcred –docker-
  server=cseregistry.rack04.cloudapp.azs.mhclabs.com –docker-username=cseadmin –docker-
  pass=’!!123abc’ –docker-email=<email địa chỉ>

Bây giờ chúng ta đã có thói quen xác minh bí mật sau khi tôi tạo nó bằng cách sử dụng lệnh sau:

kubectl lấy bí mật được đăng ký –output=”jsonpath={.data.\.dockerconfigjson}” | base64 –decode

• Sau đó, khi đến phần sửa đổi tệp YAML trong bài viết, chúng tôi đã biết được YAML nghiêm ngặt như thế nào về định dạng tệp. Khi chúng tôi thêm  đối tượng imagePullSecrets :, chúng tôi phải đảm bảo nó được xếp thẳng hàng hoàn hảo với  các thùng chứa:  đối tượng. Ngoài ra, điều thú vị cần lưu ý là các số ở cột bên phải không cần thiết phải trùng lặp.

Đây là nội dung của file đã hoạt động nhưng giao diện bài blog này sẽ không thể hiển thị chính xác phần thụt đầu dòng:

apiVersion: v1
kind: Pod                                             # 1
siêu dữ liệu:
 tên: sa-frontend
 labels:
 app: sa-frontend                                 # 2
spec: # 3
container:
 – image: cseregistry.rack04.cloudapp.azs.mhclabs.com/sentiment-analysis-frontend #4
 tên: sa-frontend                               #5
 cổng:
 – containerPort: 80                           #6
imagePullSecrets:
 – tên: regcred

Tại thời điểm này, chúng tôi đã có thể quan sát ứng dụng Trình phân tích tình cảm đầy đủ chức năng đang chạy trên cụm K8 của chúng tôi trên Azure Stack Hub. Chúng tôi không chỉ chạy ứng dụng này tại chỗ trong cụm Kubernetes tự quản lý, có tính quy định cao mà còn có thể làm như vậy trong khi tận dụng Sổ đăng ký Docker tự lưu trữ để truyền hình ảnh. Chúng tôi cũng có thể tiếp tục sử dụng Azure Monitor cho các bộ chứa bằng cổng Public Azure để giám sát ứng dụng trong bộ chứa đang chạy của mình và tạo các ngưỡng để cảnh báo kịp thời về mọi vấn đề tiềm ẩn.