Triển khai Docker Container Registry tự lưu trữ trên Azure Stack Hub
Giới thiệu
Chào mừng đến với Phần 3 của loạt bài viết gồm ba phần về việc chạy các ứng dụng chứa trong hệ sinh thái lai của Microsoft Azure. Trong phần này, chúng tôi sẽ hướng dẫn cách triển khai Docker Registry v2 tự lưu trữ, mã nguồn mở 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 dịch vụ vi mô lên sổ đăng ký tự lưu trữ rồi kéo các hình ảnh đó từ sổ đăng ký đó vào cụm K8s mà chúng tôi triển khai bằng công cụ AKS.
Sau đâ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 tại sao một tổ chức có thể muốn triển khai và duy trì sổ đăng ký container 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 không có kết nối nào cả. Cách tiếp cận 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 tương tự 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 sổ đăng ký container cục bộ. Một số khách hàng có thể chỉ cần kiểm soát chặt chẽ hơn về nơi lưu trữ hình ảnh của họ hoặc cần tích hợp lưu trữ và phân phối hình ảnh chặt chẽ 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 Registry 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 Azure Stack Hub QuickStart 101-vm-linux-docker-registry . Có hai giai đoạn cho quá trình triển khai này:
1. Tạo tài khoản lưu trữ và kho lưu trữ khóa trong nhóm tài nguyên riêng biệt bằng cách chạy tập lệnh PowerShell setup.ps1 có 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ả VM đăng ký container và các tài nguyên liên quan. Các 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 Registry. Sự khác biệt chính là mã trong kho lưu trữ msazurestackworkloads bao gồm các hiện vật để 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 Registry.
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 chứng chỉ trong khi chạy tập lệnh setup . ps1 . Chúng tôi đã sử dụng CA độc lập nội bộ của phòng thí nghiệm để tạo chứng chỉ, đây là CA giống với CA được sử dụng để triển khai cụm K8s với công cụ AKS. Chúng tôi muốn chia sẻ các bước chúng tôi đã thực hiện để lấy chứng chỉ này trong trường hợp bất kỳ độc giả nào không quen thuộc với quy trình. 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 tệp INF trô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 khai của VM đă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 = ĐÚNG
Độ dài khóa = 2048
Khóa đặc biệt = 1
Sử dụng khóa = 0xA0
MachineKeySet = Đúng
ProviderName = “Nhà cung cấp mã hóa Microsoft RSA SChannel”
Thuật toán băm = SHA256
Loại yêu cầu = PKCS10
[Chuỗi]
szOID_SUBJECT_ALT_NAME2 = “2.5.29.17”
szOID_NÂNG CẤP_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”
[Phần 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%”
[Yêu cầu Thuộc tính]
2. Chúng tôi đã sử dụng lệnh certreq.exe để tạo CSR sau đó tôi gửi cho CA.
certreq.exe -new cseregistry_req.inf 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ỉ Azure Stack PKI để 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 chứng chỉ này trong quá trình triển khai cụm K8s bằng công cụ AKS. Chứng chỉ này cần được nhập vào kho lưu trữ chứng chỉ của bất kỳ thiết bị nào có ý định tương tác với sổ đăng ký vùng chứa.
Triển khai cơ sở 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 là demoregistryinfra-rg . Nhóm tài nguyên này chứa một tài khoản lưu trữ và kho khóa. Sổ đăng ký được định cấu hình để sử dụng trình điều khiển lưu trữ Azure để lưu 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 sổ đăng ký dưới dạng bí mật và bảo mật chứng chỉ. Một hiệu trưởng dịch vụ (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.
Sau đâ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à thông tin nhạy cảm đã bị xóa). Lưu ý rằng giá trị $dnsLabelName chỉ là tên máy chủ của máy chủ đăng ký container 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 (máy khách) “
$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ý container 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 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 Registry bằng ứng dụng Sentiment Analyzer
Vào thời điểm này, đã đến lúc kiểm tra cụm K8s và sổ đăng ký container tự lưu trữ chạy trên Azure Stack Hub từ đầu đến cuối. Đối với điều này, chúng tôi đã làm theo một bài viết trên blog tuyệt vời có tiêu đề Học Kubernetes trong vòng chưa đầy 3 giờ: Hướng dẫn chi tiết về cách sắp xếp container do Rinor Maloku viết. Đâ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 dịch vụ vi mô chạy trong nhiều container. Bài viết này đề cập đến các nguyên tắc cơ bản của Docker và Kubernetes và là bài học cơ bản tuyệt vời cho bất kỳ ai mới bắt đầu trong thế giới container và sắp xếp container. Tên của ứng dụng là Sentiment Analyser và ứng dụng này sử dụng phân tích văn bản để xác định cảm xúc của một câu.
Học Kubernetes trong vòng chưa đầy 3 giờ: Hướng dẫn chi tiết về cách sắp xếp container
Chúng tôi sẽ không chia sẻ tất cả các ghi chú mà chúng tôi đã ghi lại trong khi xem qua bài viết. Tuy nhiên, có một vài mẹo mà chúng tôi muốn nêu bật khi chúng liên quan đến việc thử nghiệm cụm K8s và Docker Registry 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ị cho việc tạo ứng dụng Sentiment Analyser là thiết lập một VM 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 của phòng thí nghiệm 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 đó, chỉ cần 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 của phòng thí nghiệm. Điều này rất quan trọng để tạo điều kiện kết nối an toàn giữa VM này và VM sổ đă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 container 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ữ đang 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 quy trình đó:
- Đăng nhập vào sổ đăng ký container 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 vào sổ đăng ký container.
sudo docker tag <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 push 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
Kết quả đầu ra sau đây được đưa ra sau khi chúng tôi đẩy tất cả hình ảnh ứng dụng:
{“repositories”:[“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 CA độc lập của phòng thí nghiệm trên nút chính trước khi cố gắng kéo hình ảnh từ sổ đăng ký container. Chúng tôi cho rằng cụm đã chọn chứng chỉ gốc từ hệ thống Azure Stack Hub, vì có một tệp có tên là /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 pod K8s cho frontend Sentiment Analyser, 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 kéo hình ảnh từ các kho lưu trữ riêng tư – cho dù đó là kho lưu trữ riêng tư trên Docker Hub hay được lưu trữ riêng tư tại chỗ bằng cách sử dụng sổ đăng ký container tự lưu trữ. Chúng tôi đã làm theo hướng dẫn tại đây để tạo bí mật:
Kéo một hình ảnh từ một sổ đăng ký riêng tư
Trong phần có tiêu đề 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 của bài viết này , chúng tôi đã phát hiện ra một số mục cần lưu ý:
- Khi thực hiện lệnh kubectl create secret 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 create secret docker-registry regcred –docker-
server=cseregistry.rack04.cloudapp.azs.mhclabs.com –docker-username=cseadmin –docker-
password=’!!123abc’ –docker-email=<email address>
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 regcred –output=”jsonpath={.data.\.dockerconfigjson}” | base64 –decode
- Sau đó, khi chúng tôi đến phần sửa đổi các tệp YAML trong bài viết, chúng tôi đã biết YAML nghiêm ngặt như thế nào về định dạng của tệp. Khi chúng tôi thêm imagePullSecrets : object, chúng tôi phải đảm bảo nó hoàn toàn thẳng hàng với container: object. 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 phải sao chép.
Sau đây là nội dung của tệp đã hoạt động, nhưng giao diện bài đăng trên blog này sẽ không thể hiển thị thụt lề chính xác:
apiVersion: v1
loại: Pod # 1
siêu dữ liệu:
tên: sa-frontend
nhãn:
ứng dụng: sa-frontend # 2
đặc tả: # 3
vùng chứa:
– hình ảnh: 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 Sentiment Analyser hoạt động đầy đủ trên cụm K8s 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ể thực hiện trong khi tận dụng Docker Registry tự lưu trữ để chuyển hình ảnh. Chúng tôi cũng có thể tiến hành Azure Monitor cho các container bằng cách sử dụng cổng thông tin Public Azure để giám sát ứng dụng container đang chạy của chúng tôi và tạo ngưỡng để cảnh báo kịp thời về bất kỳ sự cố tiềm ẩn nào.

Bài viết mới cập nhật
Dell Storage Engines: Tăng tốc suy luận AI với PowerScale và ObjectScale
Giải pháp chuyển tải bộ nhớ đệm KV của Dell cho ...
Bảo vệ Nhà máy AI
Áp dụng phương pháp tiếp cận kiến trúc để bảo mật ...
Tiến lên mạnh mẽ với Dell PowerMax: Vượt mặt Hitachi VSP 5000
Dell PowerMax mang lại khả năng phục hồi, hiệu suất và ...
Đẩy nhanh đổi mới AI: Sức mạnh của quyền truy cập mở
Từ các mô hình tiên tiến đến các ứng dụng cấp ...