Ngày 4: Điện toán đám mây

Mô hình Điện toán Microsoft Azure

Tiếp theo phần trình bày về những kiếm thức cơ bản về các mô hình bảo mật trong Microsoft Azure ngày hôm qua, hôm nay chúng ta sẽ xem xét các dịch vụ điện toán khác nhau có sẵn trong Azure.

Tùy chọn khả dụng của dịch vụ (Service Availability Options)

Phần này rất gần gũi với tôi dưới vai trò Data Management. Giốn như với on-premises, điều tối quan trọng là phải đảm bảo tính khả dụng của các dịch vụ của bạn.

• Tính sẵn sàng cao (high availability) (trong một region)
• Khắm phục thảm hoạ (disaster recovery) (giữa các regions)
• Sao lưu (backup) (phục hồi từ một thời điểm)

Microsoft triển khai nhiều regions trong một ranh giới địa chính trị.

Hai khái niệm với Azure cho tính khả dụng của dịch vụ: sets và zones.

Availability Sets – Cung cấp khả năng phục hồi trong trung tâm dữ liệu

Availability Zones – Cung cấp khả năng phục hồi giữa các trung tâm dữ liệu trong một khu vực.

Máy ảo (Virtual Machines)

Gần như đây là điểm khởi đầu cho bất cứ ai làm việc với đám mây công cộng.

• Cung cấp máy ảo (VM) từ nhiều dòng và kích cỡ, cấu hình khác nhau với nhiều khả năng khác nhau (đôi khi hơi quá so với nhu cầu) Kích cỡ, cấu hình cho máy ảo của Azure
• Có nhiều tuỳ chọn và những điểm tập trung khác nhau cho máy ảo, từ hiệu năng cao, độ trễ thấp tới những máy ảo có bộ nhớ tối ưu.
• Chúng ta cũng có loại VM có thể burst (dành cho workloads vượt quá cấu hình định mức) trong dòng B. Điều này rất tốt cho các workloads mà bạn có thể yêu cầu CPU thấp hầu hết thời gian nhưng lại yêu cầu tăng đột biến với tần suất có thể là mỗi tháng một lần.
• Máy ảo được đặt trên một mạng ảo có thể cung cấp với bất cứ mạng nào khác.
• Hỗ trọ hệ điều hành Linux và Windows.
• Ngoài ra còn có các kernels được điều chỉnh cho Azure khi nói đến các bản phân phối Linux cụ thể. Azure Tuned Kernals

Tạo mẫu (Templating)

Như tôi đã đề cập trước đó, mọi thứ đằng sau hoặc bên dưới Microsoft Azure đều là JSON.

Có một số cổng quản lý và bảng điều khiển khác nhau mà chúng ta có thể sử dụng để tạo tài nguyên của mình, cách được ưu tiên là thông qua các JSON templates.

Idempotent deployments ở chế độ incremental hoặc complete – ví dụ: trạng thái mong muốn có thể được lặp lại nhiều lần (repeatable desired state)

Có nhiều lựa chọn templates có thể export các định nghĩa tài nguyên đã được triển khai. Tôi nghĩ về tính năng tạo template này là một thứ gì đó giống với AWS CloudFormation hoặc có thể là Terraform cho lựa chọn multi-cloud. Chúng ta sẽ đề cập nhiều hơn tới Terraform trong phần Cơ sở hạ tầng dưới dạng mã.

Thay đổi quy mô (Scaling)

Tự động thay đổi quy mô (automatic scaling) là một tính năng lớn của đám mây công cộng, có thể rút bớt các tài nguyên mà bạn không sử dụng hoặc tăng thêm khi bạn cần chúng.

Với Azure, chúng ta có một thứ gọi là Virtual Machine Scale Sets (VMSS) cho IaaS. Điều này cho phép tạo và scale tự động một images tiêu chuẩn theo các lịch trình và số liệu (schedules & metrics)

Việc này rất lý tưởng cho việc thiết lập các khoảng cửa sổ cập nhật (updating windows) để bạn có thể cập nhật các images và triểu khai chúng với tác động ít nhất.

Các dịch vụ khác ví dụ như Azure App Service được tích hợp sẵn tính năng tự động thay đổi quy mô (auto-scaling).

Containers

Chúng ta chưa đề cập chi tiết tới containers trong hành trình học DevOps này nhưng tôi nghĩ chúng ta cần đề cập tới việc Azure có một số dịch vụ tập trung vào containers.

Azure Kubernetes Service (AKS) – Cung cấp giải pháp quản lý Kubernetes, không cần lo lắng về control plane hay quản lý cụm tài nguyên (cluster). Chúng ta sẽ tìm hiểu về Kubernetes thêm vào phần sau.

Azure Container Instances – Containers as a service với mô hình thanh toán theo giây (per-second billing). Chạy một image và tích hợp nó với mạng ảo của bạn, không cần container orchestration (điều phối container)

Service Fabric – Có rất nhiều khả năng nhưng bao gồi điều phối các container instances.

Azure cũng có Container Registry cung cấp một registry riêng cho Docker images, Helm charts, OCI Artifacts và images. Chúng ta sẽ tìm hiểu kỹ hơn trong phần về containers.

Chúng ta cũng nên đều cập rằng rất nhiều dịch vụ container cũng có thể sử dụng container ở phía dưới nhưng điều này cũng được trừu tượng hoá và bạn không cần phải quản lý chúng.

Chúng ta cũng có thể thấy các dịch vụ tập trung vào container này xuất hiện ở mọi đám mây công cộng khác.

Application Services

• Azure Application Services cung cấp giải pháp hosting với một phương pháp đơn giản để triển khai, thiết lập dịch vụ.
• Tự động triểu khai và mở rộng quy mô.
• Hỗ trợ các giải pháp dựa trên Windows và Linux.
• Các dịnh vụ chạy trong một App Service Plan được chọn type và size.
• Thích hợp cho các dịch vụ khác nhau bao gồm wep apps, API apps và mobile apps.
• Hỗ trợ Deployment slots cho việc triển khai và kiểm thử.

Serverless Computing

Serverless đối với tôi là một chủ đề thú vị mà tôi cực kỳ muốn tìm hiểu thêm.

Mục tiêu với serverless là chúng ta chỉ trả tiền cho thời gian chạy của một hàm và không cần phải chạy các máy ảo hoặc ứng dụng PaaS mọi lúc. Chúng ta đơn giản là chỉ chạy hàm của mình khi cần và sau đó nó biến mất.

Azure Functions – Cung cấp mã serverless. Nếu chúng ta nhớ lại những điều được đề cập trong bài đầu tiên về điện toán đám mấy, chúng ta sẽ nhớ về các lớp quản lý trừu tượng, với serverless funtion, chúng ta chỉ cần quản lý code.

Event-Driven với quy mô siêu lớn, tôi có kế hoạch làm một thứ gì đó khi tôi thực hành phần này, hy vọng sẽ thực hiện được ở phần sau.

Cung cấp input và output cho nhiều dịch vụ Azure và của bên thứ ba.

Hỗ trợ nhiều ngôn ngữ lập trình. (C#, NodeJS, Python, PHP, batch, bash, Golang and Rust. hoặc bất kỳ tệp thực thi nào)

Azure Event Grid cho phép có thể kích hoạt logic từ các dịch vụ khác hoặc events.

Azure Logic App cung cấp một quy trình làm việc và tích hợp dựa trên đồ hoạ.

Chúng ta cũng có thể nhắc tơi Azure Batch, dịch vụ giúp chạy các công việc có quy mô lớn trên các nodes Windows hoặc Linux với khả năng quản lý và lập lịch nhất quán.

Mô hình lưu trữ và cơ sở dữ liệu Microsoft Azure

Các dịch vụ lưu trữ (Storage services)

• Các dịch vụ của Azure storage được cung cấp bởi các tài khoản lưu trữ(storage accounts).
• Storage accounts chủ yếu được tuỷ cập thông qua REST API.
• Một storage account phải có một tên duy nhất là và sẽ là một phần của DNS name <Storage Account name>.core.windows.net
• Có nhiều tuỳ chọn sau lưu và mã hoá khác nhau.
• Nằm trong một resource group

Chúng ta có thể tạo storage group bằng cách tìm kiếm storage group trong thành tìm kiếm ở trên cùng của Azure portal.

Chúng ta cũng có thể chọn mức độ dự phòng (redundancy) mà chúng ta muốn với storage account của mình và bất cứ thứ gì chúng ta lưu trữ ở đó. Càng xuống phía dưới danh sách, các tuỳ chọn sẽ ngày một đắt tiền nhưng dữ liệu của bạn cũng được bảo đảm hơn.

Ngay cả tuỳ chọn dự phòng mặc định cũng cung cấp cho chúng ta 3 bản sau dữ liệu.

Azure Storage Redundancy

Dưới đây là tóm tắt cho thông tin có trong đường link ở trên:

• Locally-redundant storage – sao chép dữ liệu của bạn ba lần trong một trung tâm dữ liệu ở khu vực chính.
• Geo-redundant storage – sao chép đồng bộ dữ liệu của bạn ba lần tại một vị trí vật lý ở khu vực chính sử dụng LRS.
• Zone-redundant storage – sao chép dữ liệu của bạn một cách đồng bộ trên ba vùng khả dụng của Azure trong vùng chính.
• Geo-zone-redundant storage – kết hợp tính khả dụng cao do khi các dữ liệu được sao chép giữa các availability zones (AZ) với khả năng bảo vệ khỏi sự cố với một region bằng geo-replication. Dữ liệu trong GZRS storage account được sao chép qua ba AZs trong region chính và cũng được sao chép sang vùng địa lý thứ hai để bảo về các thảm hoạ xảy ra trong từng khu vực.

Quay trở lại các tuỳ chọn về hiệu suất. Chúng ta có Standard và Premium để chọn. Chúng ta đã chọn Standard trong hướng dẫn này nhưng lựa chọn Premium cho chúng ta một số ưu điểm cụ thể.

Sau đó, trong drop-down, bạn có thể thấy chúng ta có ba tuỳ chọn sau.

Có rất nhiều tuỳ chọn nâng cao hơn có sẵn cho tài khoản lưu trữ của bạn, nhưng hiện tại, chúng tôi không cần phải truy cập vào các phần này. Các tuỳ chọn này là về mã hoá và bảo vệ dữ liệu.

Ổ đĩa được quản lý – Managed Disks

Truy cập bộ nhớ có thể đạt được theo một vài cách sau:

Truy cập được xác thực thông qua:

• Một shared key để kiểm soát hoàn toàn
• Shared Access Signature để truy cập, uỷ quyền truy cập.
• Azure Active Directory (nếu có)

Truy cập công cộng:

• Quyền truy cập công khai cũng có thể được cấp để cho phép truy cập ẩn danh bao gồm cả qua HTTP.
  • Một ví dụ về điều này có thể là lưu trữ các tệp và nội dung cơ bản trong một khối blob để trình duyệt có thể xem và tài xuống dữ liệu này.

Nếu bạn đang truy cập vào bộ nhớ của mình từ một dịch vụ Azure khác, thì lưu lượng truy cập vẫn nằm trong Azure.

Khi nói đến hiệu xuất lưu trữ, chúng ta có 2 loại khác nhau:

• Tiêu chuẩn – Số lượng IOPS tối đa trong khả năng
• Premium – Số lượng IOPS được đảm bảo

IOPS => Input/Output operations per sec.

Ngoài ra còn có sự khác biết giữa ổ đĩa không được quản lý và ổ đĩa được quản lý để cân nhắc khi chọn ổ lưu trữ phù hợp cho tác vụ của bạn.

Lưu trữ trên máy ảo – Virtual Machine Storage

• Ổ đĩa của hệ điều hành máy ảo được lưu trữ trên bộ lưu trữ liên tục (persisten storage)
• Một số workloads phi trạng thái không yêu cầu lưu trữ liên tục và việc giảm độ trễ là điều cần quan tâm hơn.
• Có một số máy ảo hỗ trợ các ổ đĩa tạm thời (ephemeral disks) do hệ điều hành quản lý và được tạo trên bộ lưu trữ nút cục bộ (node-local storage)
  • Chúng cũng có thể được sử dụng với VM Scale Sets

Ổ đĩa được quản lý là bộ lưu trữ khối (block storage) có thể được sử dụng với Azure Virtual Machines. Bạn có thể có Ultra Disk Storage, Premium SSD, Standard SSD, hoặc Standard HDD. Chúng cũng có một số đặc điểm riêng.

• Hỗ trợ Snapshot và Image
• Di chuyển đơn giản giữa các SKUs
• Tính khả dụng tốt hơn khi kết hợp với các bộ tính khả dụng (availability sets)
• Tính phí dựa trên kích thước đĩa, không phải trên dung lượng lưu trữ đã sử dụng.

Lưu trữ kho – Archive Storage

• Cool Tier – Có sẵn cho block và các blobs có thể thêm dữ liệu (append blobs)
  • Chi phí lưu trữ thấp hơn
  • Chi phí đọc/ghi cao hơn

• Archive Tier – Có sẵn cho block BLOBs.
  • Được định cấu hình trên mỗi BLOB.
  • Chi phí rẻ hơn nhưng độ trễ khi truy vấn dữ liệu cao hơn.
  • Có độ bền bỉ (durability) tương tự như Azure Storage thông thường.
  • Phân tầng dữ liệu tuỳ chỉnh có thể được bật theo yêu cầu.

Chia sẻ file – File Sharing

Từ việc tạo storage account ở trên, giờ đây chúng ta có thể tạo chia sẻ tệp.

Việc này sẽ cung cấp tính năng chia sẻ tệp SMB2.1 và 3.0 trong Azure.

Có thể sử dụng trong Azure và bên ngoài thông qua SMB3 và cổng 445 mở ra với Internet.

Cung cấp lưu trữ tệp được chia sẻ trong Azure.

Ngoài REST API, dữ liệu có thể được đọc bởi ứng dụng SMB client tiêu chuẩn

Bạn cũng có thể để ý đến Azure NetApp Files (SMB and NFS)

Bộ nhớ đệm & Dịch vụ media – Caching & Media Services

Azure Content Delivery Network cung cấp bộ nhớ đệm cho nội dung web tĩnh với các vị trí trên khắp thế giới.

Azure Media Service, cung cấp các công nghệ chuyển mã phương tiện bên cạnh các dịch vụ phát lại.

Mô hình cơ sở dữ liệu Microsoft Azure

Chúng ta đã đề cập đến nhiều tùy chọn dịch vụ khác nhau. Một trong số đó là PaaS (Nền tảng dưới dạng Dịch vụ), nơi bạn trừu tượng hóa một các cơ sở hạ tầng và hệ điều hành và chỉ còn lại quyền kiểm soát ứng dụng hoặc trong trường hợp này là các mô hình cơ sở dữ liệu.

Relational Databases

Cơ sở dữ liệu Azure SQL cung cấp cơ sở dữ liệu quan hệ dưới dạng dịch vụ dựa trên Microsoft SQL Server.

Đây là SQL chạy nhánh SQL mới nhất với mức độ tương thích cơ sở dữ liệu có sẵn khi cần có một phiên bản chức năng cụ thể.

Có một vài tùy chọn về cách cấu hình điều này, chúng ta có thể cung cấp một cơ sở dữ liệu duy nhất tron instance, trong khi một nhóm đàn hồi (elastic pool) cho phép nhiều cơ sở dữ liệu chia sẻ một nhóm dung lượng và chia tỷ lệ với nhau.

Các instances cơ sở dữ liệu này có thể được truy cập như các bản SQL thông thường.

Các dịch vụ được quản lý khác như MySQL, PostgreSQL và MariaDB.

Giải pháp NoSQL

Azure Cosmos DB là một NoSQL bất khả tri (agnostic NoSQL) với 99.99% SLA.

Dữ liệu được phân phối toàn cầu với độ trễ một chữ số cho 99% số yêu cầu ở mọi nơi trên thế giới với tính năng tự động điều hướng.

Khoá phân vùng (Partition key) được tận dụng để phân vùng/phân mảnh/phân phối dữ liệu.

Hỗ trợ nhiều mô hình dữ liệu khác nhau (documents, key-value, graph, column-friendly)

Hỗ trợ nhiều API khác nhau (DocumentDB SQL, MongoDB, Azure Table Storage và Gremlin)

Có nhiều mô hình nhất quán khác nhau dựa trên định lý CAP.

Bộ nhớ đệm – Caching

Để tránh đi sâu vào các hệ thống bộ nhớ đệm như Redis, tôi chỉ muốn đề cập rằng Microsoft Azure có một dịch vụ gọi là Azure Cache cho Redis.

Azure Cache cho Redis cung cấp bộ nhớ lưu trữ dữ liệu in-memory dựa trên Redis.

• Đây là một phiên bản triển khai của phần mềm mã nguồn mở Redis Cache.
  • Một instance được host, bảo mật
  • Có nhiều tiers khác nhau để lựa chọn
  • Ứng dụng phải được cập nhật để tận dụng bộ nhớ đệm
  • Nhắm vào các ứng dụng có yêu cầu đọc nhiều hơn so với ghi
  • Lưu trữ dưới dạng key-value

Đã có rất nhiều ghi chú và lý thuyết về Microsoft Azure nhưng tôi muốn đề cập kỹ hơn tới các khối xây dựng cơ bản (building blocks) trước khi chúng ta đi sâu vào các khía cạnh thực hành về cách các thành phần này kết hợp và hoạt động với nhau.

Chúng ta còn một chút lý thuyết nữa về mạng trước khi có thể thiết lập và triển khai và chạy một số dịch vụ dựa trên các kịch bản có sẵn. Chúng ta cũng nên tương tác với Microsoft Azure bằng các phương pháp khác nhau so với việc chỉ sử dụng cổng portal như chúng ta vẫn làm cho tới thời điểm này.

Mô hình Mạng Microsoft Azure + Quản lý Azure

Hôm nay là ngày kỷ niệm của Microsoft Azure và Sinh nhật lần thứ 12 của nó! (Ngày 1 tháng 2 năm 2022) Dù sao đi nữa, chúng ta sẽ đề cập đến các mô hình kết nối mạng trong Microsoft Azure và một số tùy chọn quản lý dành cho Azure. Cho đến hiện tại, chúng ta mới chỉ sử dụng Azure portal nhưng chúng ta đã đề cập đến một số phần và phương pháp khác để tạo các tài nguyên trên nền tảng này.

Mô hình mạng Azure

Mạng ảo – Virtual Networks

• Mạng ảo (VNet) là một cấu trúc được tạo trong Azure.
• Một mạng ảo có một hoặc nhiều dải IP được gán cho nó.
• Mạng ảo tồn tại trong một subscription trong một region.
• Mạng con ảo (virtual subnets) được tạo trong mạng ảo để chia nhỏ phạm vi mạng.
• Máy ảo được đặt trong mạng con ảo.
• Tất cả các máy ảo trong một mạng ảo đều có thể giao tiếp với nhau.
• 65.536 IPs riêng trên mỗi Mạng ảo.
• Chỉ trả tiền cho lưu lượng đi ra từ một region. (Dữ liệu rời khỏi region)
• Hỗ trợ IPv4 & IPv6.
  • IPv6 dành cho public-facing và trong các mạng ảo.

Chúng ta có thể ví Mạng ảo Azure với AWS VPC. Tuy nhiên, có một số khác biệt cần lưu ý:

• Trong AWS, VNet mặc định được tạo, điều này không giống với Microsoft Azure, bạn phải tạo mạng ảo đầu tiên theo yêu cầu của mình.
• Tất cả các Virtual Machines mặc định trong Azure đều có NAT truy cập internet. Không có NAT Gateways như AWS.
• Trong Microsoft Azure không có khái niệm mạng con Private hay Public.
• IP công cộng là tài nguyên có thể được gán cho vNIC hoặc Bộ cân bằng tải.
• Mạng ảo và Mạng con có ACL riêng cho phép ủy quyền cấp mạng con.
• Mạng con trên các AZs trong khi ở AWS, bạn có các mạng con nằm trên một AZ.

Chúng ta cũng có Virtual Network Peering. Điều này cho phép các mạng ảo trên các tenants và regions được kết nối thông qua hạ tầng của Azure. Không có tính bắc cầu nhưng nhưng có thể được kích hoạt qua Azure Firewall trong hub virtual network.

Kiểm soát truy cập – Access Control

• Azure sử dụng Network Security Groups, đây là những nhóm có trạng thái.
• Kích hoạt các quy tắc được tạo và sau đó được gán cho một Network Security Group
• Network Security Groups được áp dụng cho mạng con hoặc máy ảo.
• Khi được áp dụng cho một mạng con, nó vẫn được thực thi tại NIC của máy ảo rằng nó không phải là thiết bị “Edge”.

• Các quy tắc được kết hợp trong một Network Security Group.
• Dựa trên mức độ ưu tiên, có thể cấu hình linh hoạt.
• Số ưu tiên thấp hơn có nghĩa là ưu tiên cao.
• Hầu hết logic được xây dựng bởi Địa chỉ IP nhưng một số thẻ và nhãn cũng có thể được sử dụng.

Chúng tôi cũng có Application Security Groups (ASGs)

• Trường hợp NSG tập trung vào dải địa chỉ IP có thể khó duy trì đối với môi trường đang phát triển.
• ASG cho phép xác định tên thật (Monikers) cho các vai trò ứng dụng khác nhau (Máy chủ web, máy chủ DB, WebApp1, v.v.)
• NIC của máy ảo được coi là thành viên của một hoặc nhiều ASG.

Sau đó, ASG có thể được sử dụng trong các quy tắc và là một phần của Network Security Groups để kiểm soát luồng giao tiếp và vẫn có thể sử dụng các tính năng của NSG như tags của dịch vụ.

Cân bằng tải – Load Balancing

Microsoft Azure có hai giải pháp cân bằng tải riêng biệt. (giải phảp first party, có nhiều giải pháp của bên thứ ba trên Azure marketplace) Cả hai đều có thể hoạt động với các endpoints nội bộ hoặc công khai.

• Load Balancer (Layer 4) hỗ trợ phân phối và chuyển tiếp cổng dựa trên hàm băm.
• App Gateway (Layer 7) hỗ trợ các tính năng như giảm tải SSL, định tuyến dựa trên cookie và định tuyến nội dung dựa trên URL.

Ngoài ra với App Gateway, bạn có thể tùy chọn sử dụng Web Application firewall.

Công cụ quản lý Azure – Azure Management Tools

Chúng ta đã dành phần lớn thời gian lý thuyết của mình để xem qua Azure portal, tôi khuyên bạn nên tuân theo văn hóa DevOps và thực hiện các các task, đặc biệt là xung quanh việc khởi tạo tài nguyên nên được thông qua API hoặc công cụ dòng lệnh (CLI). Tôi muốn đề cập đến một số công cụ quản lý có sẵn khác vì chúng ta cần biết điều này khi tự động hóa việc khởi tạo và quản lý môi trường Azure của mình.

Azure Portal

Microsoft Azure portal là một bảng điều khiển bằng web, cung cấp giải pháp thay thế cho các công cụ dòng lệnh. Bạn có thể quản lý subscriptions của mình trong Azure portal. Xây dựng, quản lý và giám sát mọi thứ từ một ứng dụng web đơn giản đến việc triển khai hệ thống phức tạp. Một thứ khác mà bạn sẽ tìm thấy trong portal là các breadcrumbs này, JSON như đã đề cập trước đây là nền tảng của tất cả tài nguyên trên Azure. Có thể bạn bắt đầu với portal để hiểu các tính năng, dịch vụ và chức năng nhưng sau đó nên hiểu các file JSON ở dưới đó để kết hợp vào quy trình làm việc tự động của bạn.

Ngoài ra còn có Azure Preview portal, nó có thể được sử dụng để xem và thử nghiệm các dịch vụ và cải tiến mới và sắp ra mắt.

PowerShell

Trước khi chúng tôi bắt đầu với Azure PowerShell, chúng ta nên biết tới PowerShell. PowerShell là một framework quản lý cấu hình và tự động hóa tác vụ, một command-line shell và ngôn ngữ kịch bản. Nó giống với những gì chúng ta đã tìm hiểu trong phần shell scripting cho Linux. PowerShell lúc đầu được sử dụng rộng rãi trên hệ điều hành Windows nhưng giờ đây nó đã có trên nhiều nền tảng.

Azure PowerShell là một tập hợp các lệnh ghép ngắn để quản lý tài nguyên Azure trực tiếp từ dòng lệnh PowerShell.

Chúng ta có thể thấy bên dưới rằng bạn có thể kết nối với đăng ký của mình bằng lệnh PowerShell Connect-AzAccount

Sau đó, nếu muốn tìm một số lệnh cụ thể được liên kết với máy ảo Azure, chúng ta có thể chạy lệnh sau. Bạn có thể dành thời gian để học và tìm hiểu thêm về ngôn ngữ lập trình này.

Có một số hướng dẫn nhanh rất tốt từ Microsoft về việc bắt đầu và khởi tạo các dịch vụ từ Powershell tại đây

Visual Studio Code

Giống như nhiều người, và như tất cả các bạn đã thấy, IDE của tôi là Visual Studio Code.

Visual Studio Code là trình chỉnh sửa mã nguồn miễn phí do Microsoft tạo cho Windows, Linux và macOS.

Bạn sẽ thấy bên dưới có rất nhiều tích hợp và công cụ được tích hợp trong Visual Studio Code mà bạn có thể sử dụng để tương tác với Microsoft Azure và các dịch vụ trong đó.

Cloud Shell

Azure Cloud Shell là một shell tương tác, được xác thực, có thể truy cập bằng trình duyệt để quản lý tài nguyên Azure. Nó cung cấp sự linh hoạt khi lựa chọn shell phù hợp nhất với người dùng.

Bạn có thể thấy từ bên dưới khi khởi chạy Cloud Shell lần đầu tiên trong portal, chúng ta có thể chọn giữa Bash và PowerShell.

Để sử dụng cloud shell, bạn sẽ phải cung cấp một chút dung lượng lưu trữ trong subscription của mình.

Khi bạn chọn sử dụng cloud shell, nó sẽ khởi động một máy, những máy này là tạm thời nhưng các tệp của bạn vẫn được duy trì theo hai cách: thông qua disk image và mounted file share.

• Cloud Shell chạy trên máy chủ tạm thời được cung cấp trên theo mỗi phiên, mỗi người dùng
• Cloud Shell hết thời gian chờ sau 20 phút không có hoạt động tương tác
• Cloud Shell yêu cầu một Azure file share được gắn vào (mounted)
• Cloud Shell sử dụng cùng một Azure file share cho cả Bash và PowerShell
• Cloud Shell được cung cấp một máy cho mỗi tài khoản người dùng
• Cloud Shell vẫn duy trì $HOME bằng cách sử dụng hình ảnh 5 GB được giữ trong file share của bạn
• Quyền được đặt như một người dùng Linux thông thường trong Bash

Phần trên được sao chép từ Tổng quan về Cloud Shell

Azure CLI

Cuối cùng, tôi muốn đề cập đến Azure CLI, Azure CLI có thể được cài đặt trên Windows, Linux và macOS. Sau khi cài đặt, bạn có thể nhập az theo sau là các lệnh khác để tạo, cập nhật, xóa và xem tài nguyên trên Azure.

Khi mới bắt đầu học Azure, tôi hơi bối rối vì có Azure PowerShell và Azure CLI.

Tôi cũng thích có phản hồi từ cộng đồng về điều này. Nhưng theo cách tôi thấy thì Azure PowerShell là một module được thêm vào Windows PowerShell hoặc PowerShell Core (cũng có sẵn trên hệ điều hành khác nhưng không phải tất cả), trong khi Azure CLI là một chương trình dòng lệnh đa nền tảng kết nối với Azure và thực thi các lệnh đó .

Cả hai tùy chọn này đều có cú pháp khác nhau, mặc dù từ những gì tôi có thể thấy và những gì tôi đã làm chúng có thể thực hiện các nhiệm vụ rất giống nhau.

Ví dụ: tạo một máy ảo từ PowerShell sẽ sử dụng lệnh ghép ngắn New-AzVM trong khi Azure CLI sẽ sử dụng az VM create.

Trước đây, bạn có thể thấy rằng tôi đã cài đặt module Azure PowerShell trên hệ thống của mình nhưng sau đó tôi cũng đã cài đặt Azure CLI và nó có thể được gọi thông qua PowerShell trên máy Windows của mình.

Bài học rút ra ở đây như chúng ta đã đề cập là chọn công cụ phù hợp với bản thân. Azure chạy trên tự động hóa. Mọi hành động bạn thực hiện bên trong portal sẽ được dịch ở đâu đó thành dạnh mã và được thực thi để đọc, tạo, sửa đổi hoặc xóa tài nguyên.

Azure CLI

• Giao diện dòng lệnh đa nền tảng, có thể cài đặt trên Windows, macOS, Linux
• Chạy trong Windows PowerShell, Cmd, Bash và các shell Unix khác.

Azure PowerShell

• Module PowerShell đa nền tảng, chạy trên Windows, macOS, Linux
• Yêu cầu Windows PowerShell hoặc PowerShell

Nếu có lý do khiến bạn không thể sử dụng PowerShell trong môi trường của mình nhưng bạn có thể sử dụng bash thì Azure CLI sẽ là lựa chọn của bạn.

Tiếp theo, chúng ta sử dụng tất cả các lý thuyết đã được đề cập và tạo ra một số kịch bản và thực hành trên Azure.

Thực hành với Microsoft Azure

Chúng ta đã tập trung vào Microsoft Azure nói riêng và đám mây công cộng nói chung trong suốt 6 ngày qua, phần lớn các kiến thức này chứa nhiều lý thuyết để hiểu được các khối xây dựng cơ bản của Azure, nhưng điều này cũng cũng sẽ có thể liên kết và áp dụng với các nhà cung cấp đám mây khác.

Tôi đã đề cập ngay từ đầu về việc có kiến thức cơ bản về đám mấy công cộng và chọn ít nhất một nhà cung cấp để bắt đầu, nếu bạn đang nhảy giữa các đám mây khác nhau thì tôi tin rằng rất dễ bị rối. Trong khi chọn một nhà cung cấp và sau khi hiểu các nguyên tắc cơ bản, bạn sẽ dễ dàng học, tìm hiểu về những đám mây khác và tăng tốc việc học của mình.

Trong bài cuối cùng này, tôi sẽ chọn và chọn các tình huống thực hành của mình từ trang này. Đây là tài liệu tham khảo do Microsoft tạo và được sử dụng để chuẩn bị cho AZ-104 Microsoft Azure Administrator

Có một số ví dụ ở đây chẳng hạn như Container và Kubernetes, các chủ đề chưa được đề cập đến vì vậy tôi chưa muốn đi sâu vào chúng.

Trong các bài viết trước, chúng ta đã tạo hầu hết các Module 1,2 và 3.

Mạng ảo – Virtual Networking

Làm theo Module 04:

Tôi đã xem qua phần trên và thay đổi một vài tên cho phù hợp với #90DaysOfDevOps. Thay vì sử dụng Cloud Shell, tôi cũng đã đăng nhập bằng người dùng mới được tạo vào những ngày trước sử dụng Azure CLI trên máy Windows của mình.

Bạn có thể làm điều này bằng cách sử dụng az login, sau đó một trình duyệt sẽ được mở và cho phép bạn xác thực tài khoản của mình.

Sau đó, tôi đã tạo tập lệnh PowerShell và tham khảo từ module để sử dụng nhằm xây dựng một số tác vụ bên dưới. Bạn có thể tìm thấy các tập tin liên quan trong thư mục này. (Cloud\01VirtualNetworking)

Vui lòng đảm bảo rằng bạn thay đổi vị trí tệp trong tập lệnh phù hợp với môi trường của mình.

Ở giai đoạn đầu tiên này, chúng tôi không có mạng ảo hoặc máy ảo nào được tạo trong môi trường của mình, tôi chỉ có một cloud shell storage được định cấu hình trong resource group của mình.

Trước hết, tôi chạy PowerShell script của mình

• Nhiệm vụ 1: Tạo và cấu hình mạng ảo

• Nhiệm vụ 2: Triển khai máy ảo vào mạng ảo

• Nhiệm vụ 3: Cấu hình địa chỉ IP private và public của máy ảo Azure

• Nhiệm vụ 4: Cấu hình các network security groups

• Nhiệm vụ 5: Cấu hình Azure DNS để phân giải tên nội bộ

Quản lý lưu lượng mạng – Network Traffic Management

Làm theo Module 06:

Hướng dẫn tiếp theo, từ hướng dẫn cuối cùng, chúng ta đã vào resource group và xoá tài nguyên của mình. Nếu bạn chưa thiết lập tài khoảng người dùng như tôi để chỉ có quyền truy cập vào một nhóm tài nguyên đó, bạn có thể làm theo module đổi tên thành 90Days*, điều này sẽ xoá tất cả các tài nguyên và nhóm tài nguyên. Đây sẽ là quy trình của tôi cho tất cả các bài labs sau này.

Đối với lab này, tôi cũng đã tạo tập lệnh PowerShell và một số tài liệu tham khảo từ module sử dụng cho việc xây dựng một số tác vụ bên dưới. Bạn có thể tìm thấy các tập tin liên quan trong thư mục này. (Cloud\02TrafficManagement)

• Nhiệm vụ 1: Tạo môi trường cho lab

Đầu tiên tôi chạy PowerShell script của mình

• Nhiệm vụ 2: Cấu hình topo mạng cho mạng hub-spoke

• Nhiệm vụ 3: Kiểm tra tính bắc cầu của virtual network peering

Group 90DaysOfDevOps của tôi không có quyền truy cập vào Network Watcher do không có quyền, tôi cho rằng điều này là do Network Watcher là một trong những tài nguyên không được liên kết với nhóm tài nguyên mà RBAC của chúng ta đã khai báo. Tôi đã thêm vai trò East US Network Watcher contributor vào group 90DaysOfDevOps.

^ Điều này được mong đợi vì hai spoke virtual networks không peer với nhau (network peering không mang tính bắc cầu).

• Nhiệm vụ 4: Cấu hình định tuyến trong topo hub-spoke

Tôi gặp một vấn đề khác ở đây là tài khoản của tôi không thể chạy tập lệnh với tư cách là người dùng trong nhóm 90DaysOfDevOps và vì không chắc lắm nên tôi đã quay lại tài khoản quản trị viên chính của mình. Nhóm 90DaysOfDevOps là chủ sở hữu của mọi thứ trong Nhóm tài nguyên 90DaysOfDevOps, vì vậy tôi rất muốn hiểu tại sao tôi không thể chạy lệnh bên trong VM?

Sau đó, tôi có thể quay lại tài khoản [email protected] của mình và tiếp tục phần này. Ở đây chúng tôi đang chạy lại vài bài test tương tự nhưng bây giờ đã có thể truy cập được.

Nhiệm vụ 5: Triển khai Azure Load Balancer

Nhiệm vụ 6: Triển khai Azure Application Gateway

Azure Storage

Làm theo Module 07:

Đối với phòng thí nghiệm này, tôi cũng đã tạo tập lệnh PowerShell và tham khảo từ module sử dụng cho việc xây dựng một số tác vụ bên dưới. Bạn có thể tìm thấy các tập tin liên quan trong thư mục này. (Cloud\03Storage)

• Nhiệm vụ 1: Tạo môi trường cho lab

Trước hết, tôi chạy PowerShell script của mình

• Nhiệm vụ 2: Tạo và cấu hình tài khoản Azure Storage

• Nhiệm vụ 3: Quản lý lưu trữ blob

• Nhiệm vụ 4: Quản lý xác thực và cấp quyền cho Azure Storage

Tôi hơi thiếu kiên nhẫn chờ đợi điều này được cho phép nhưng cuối cùng thì nó cũng hoạt động.

• Nhiệm vụ 5: Tạo và cấu hình Azure file share

Khi chạy lệnh, lệnh này sẽ không hoạt động với [email protected] nên tôi đã sử dụng tài khoản admin của mình.

• Nhiệm vụ 6: Quản lý truy cập mạng cho Azure Storage

Serverless (Triển khai ứng dụng web)

Làm theo Module 09a:

• Nhiệm vụ 1: Tạo Azure web app

• Nhiệm vụ 2: Tạo staging deployment slot

• Nhiệm vụ 3: Định cấu hình cài đặt triển khai ứng dụng web

• Nhiệm vụ 4: Triển khai mã vào staging deployment slot

• Nhiệm vụ 5: Đổi staging slots

• Nhiệm vụ 6: Định cấu hình và kiểm tra tính năng tự động thay đổi quy mô (auto-scaling)của Azure web app

Tập lệnh tôi đang sử dụng có thể được tìm thấy trong (https://github.com/vntechies/90DaysOfDevOps/tree/main/2022/Days/Cloud/04Serverless)

Bài lab này kết thúc phần tìm hiểu về Microsoft Azure nói riêng và đám mây công cộng nói chung. Tôi có thể nói rằng tôi đã rất vui khi thử sức và giải quyết các tình huống trên đây.

Tài liệu tham khảo

• Hybrid Cloud and MultiCloud
• Microsoft Azure Fundamentals
• Google Cloud Digital Leader Certification Course
• AWS Basics for Beginners – Full Course

Vậy là đã kết thúc ngày 4 trong Lộ trình học DevOps trong 12 ngày

Tiếp theo, chúng ta sẽ đi sâu vào các hệ thống kiểm soát phiên bản, cụ thể là xung quanh git và sau đó là tổng quan về kho lưu trữ mã và chúng tôi sẽ chọn GitHub vì đây là lựa chọn ưa thích của tôi.

Hẹn gặp lại vào Ngày 5: Sử dụng Git hiệu quả

Các bài viết là bản tiếng Việt của tài liệu 90DaysOfDevOps của Micheal Cade và có qua sửa đổi, bổ sung. Tất cả đều có license [Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License][cc-by-nc-sa]

Mọi thắc mắc xin hãy liên hệ
Email: [email protected]

(Nguồn: vntechies.dev)