DevOps VietNam

Đăng nhập
Đăng ký
Đăng nhập

Các tasks thực hành DevOps giúp nâng cao kỹ năng (Junior+)

Các tasks DevOps dưới đây anh em làm để nâng kỹ năng hoặc anh em nào mới chưa biết task thực hành thì làm nhé. Mình xếp theo cấp độ. Tuy nhiên, năm kinh nghiệm chỉ phản án được phần nào của trình độ thật sự dựa theo trải nghiệm của anh em. Chắc chắn là có những bạn có năm kinh nghiệm được tính bằng Junior nhưng thực lực thật sự sự có thể hơn rất nhiều. Nên anh em làm task để lấy giá trị cốt lõi nhé.

Các Tasks mình có gợi ý để ở cuối bài viết, anh em nên lab thử trước xong xem cách gợi ý nhé, vì gợi ý là của cá nhân nên biết đâu anh em có nhiều cách hay khác. Nếu anh em xem nhiều và hữu ích thì mình chia sẻ thêm “nhiều task nữa”. Bình tĩnh, tự tin, khiêm tốn :D

1. K8s StatefulSet Deployment (Junior)

Tình huống

Một công ty đang triển khai hệ thống web sử dụng Redis làm cache cho ứng dụng. Redis cần được triển khai đúng theo chuẩn Production với khả năng lưu trữ dữ liệu ổn định và có thể mở rộng. Hãy hoàn thành tệp YAML mẫu tại: /home/devops/mrzero-task1/special-definition.yml.

Yêu cầu

  • Tạo một namespace mới tên là mrzero.
  • Triển khai Redis từ DockerHub, sử dụng image redis:buster, dưới dạng StatefulSet tên là cache-db, trong namespace mrzero.
  • Cấu hình StatefulSet với 2 replicas, mỗi pod có volume riêng.
  • Mỗi pod Redis mở cổng 6379 để nhận kết nối.
  • Tạo kèm một Headless Service để các pod có thể giao tiếp với nhau nếu cần (DNS theo kiểu cache-db-0.cache-db.mrzero.svc.cluster.local).
  • Sử dụng PersistentVolumeClaim để đảm bảo Redis có dữ liệu ổn định.

Ghi chú

  • Giải pháp phải được viết trong tệp /home/devops/mrzero/special-definition.yml.

  • Tất cả thao tác sẽ được kiểm tra thông qua một lệnh duy nhất:

    sudo execute

    được chạy từ thư mục /home/devops/mrzero-task1/.

  • Có quyền sudo nếu cần thiết.

Dưới đây là bản dịch tiếng Việt chuẩn + phần đánh giá mức độ thực tế và độ khó của bài toán Linux Automation:

2. Linux Automation (Junior/Middle)

Tình huống

Hãy hoàn thiện file script mẫu nằm tại: task2/runscript.sh bằng cách viết một hoặc nhiều lệnh shell.

Yêu cầu

  1. Giải nén tập tin nén có sẵn tại đường dẫn /task2/backup.tar.gz.
  2. Gán quyền truy cập 0664 cho tất cả các tệp vừa được giải nén.
  3. Gán quyền truy cập 0775 cho tất cả các thư mục vừa được giải nén.
  4. Thay đổi chủ sở hữu thành anonymous và nhóm thành no-team cho toàn bộ file và thư mục đã giải nén.
  5. Tạo lại một bản nén mới có tên là /tmp/fixed-archive.tar.gz chứa toàn bộ nội dung sau khi đã chỉnh sửa quyền và chủ sở hữu.

Ghi chú

  • Mọi thao tác phải được thực hiện bên trong thư mục /task2.
  • Việc chấm bài sẽ được thực hiện trong một môi trường mới hoàn toàn, do đó mọi thứ cần được thực hiện đúng từ /task2.
  • Tất cả các tác vụ cần được thực hiện chỉ bằng một lệnh sudo activate, được chạy từ thư mục câu hỏi (tức là /task2). (Gợi ý: dùng alias hoặc shell script)
  • Bạn có quyền sudo nếu cần.

3. Cải tiến Kubernetes (Junior/Mid)

Tình huống

Trong quá trình cải tiến cụm Kubernetes, bạn cần thiết lập một tác vụ định kỳ (recurring task) để gọi đến một API từ xa. Câu hỏi đặt ra là:

Lệnh nào sau đây là đúng để thực hiện tác vụ đó?

  1. kubectl run cronjob task --image=toolbox --schedule="*/1 * * * *" -- curl -s https://api.cyber-widget.com/refresh
  2. kubecmd create periodic-task --image=toolbox --timing="/1 * * * *" -- curl -s https://api.cyber-widget.com/refresh
  3. kubecmd run periodic task --image=toolbox --timing="*/1 * * * *" -- curl -s https://api.cyber-widget.com/refresh
  4. kubectl create cronjob task --image=toolbox --schedule="*/1 * * * *" -- curl -s https://api.cyber-widget.com/refresh

Ghi chú

  • Đáp án đúng sẽ được đánh giá dựa trên khả năng thiết lập đúng cronjob để thực hiện tác vụ định kỳ gọi API như mô tả.

4. CI/CD Pipeline với GitHub Actions (Junior)

Tình huống

Bạn đang chịu trách nhiệm thiết lập quy trình CI/CD cho một ứng dụng web viết bằng Python + Flask. Mã nguồn của ứng dụng đang được lưu trữ trên GitHub.

Mục tiêu

Tạo một workflow GitHub Actions đáp ứng các yêu cầu sau:

  1. Kích hoạt workflow khi:

    • Có push lên nhánh main
    • Có pull request nhằm vào nhánh main
  2. Sử dụng môi trường Python 3.x
  3. Cài đặt các package được định nghĩa trong file requirements.txt
  4. Chạy unit test nằm trong thư mục tests/
  5. Nếu unit test thành công và workflow được kích hoạt bởi push lên nhánh main, thì tiến hành triển khai ứng dụng lên một máy chủ cloud (AWS, Azure, v.v.)

Ghi chú

  • Chỉ sử dụng một file YAML duy nhất để cấu hình workflow GitHub Actions
  • Giả định rằng bạn đã có đầy đủ thông tin xác thực (credentials) để triển khai lên cloud

5. GitOps với ArgoCD (Junior/Middle)

Tình huống

Team đang chuyển sang triển khai ứng dụng Kubernetes theo mô hình GitOps với ArgoCD. Nhiệm vụ của bạn là thiết lập pipeline GitOps đầu tiên để triển khai một ứng dụng mẫu từ Git vào cụm Kubernetes.

Mục tiêu

Thiết lập toàn bộ luồng GitOps với ArgoCD:

  1. Fork một repository ứng dụng mẫu (giả định là ứng dụng Nginx đơn giản chạy qua Deployment + Service).
  2. Cài đặt ArgoCD lên Kubernetes cluster (có thể dùng Minikube hoặc Rancher Desktop).
  3. Tạo ArgoCD Application để triển khai ứng dụng từ repo bạn vừa fork.
  4. Thực hiện thay đổi trong mã nguồn (hoặc YAML), push lên Git, xác nhận rằng ArgoCD tự động cập nhật deployment.
  5. Cấu hình chiến lược rollback, đảm bảo có thể quay lại version trước nếu cần.

6. Triển khai Kubernetes Cluster bằng Terraform (Upper-Middle)

Tình huống

Công ty đang trong quá trình di chuyển các ứng dụng sang Kubernetes và sử dụng Terraform để quản lý hạ tầng. Nhiệm vụ của bạn là triển khai một cụm Kubernetes cùng với các tài nguyên thiết yếu bằng Terraform.

Yêu cầu

  • Khởi tạo một dự án Terraform mới trong repository Git của bạn.
  • Sử dụng module Terraform để tạo một cụm Kubernetes trên một nhà cung cấp cloud bất kỳ (AWS, GCP hoặc Azure).

  • Sau khi cụm được khởi tạo, tiếp tục dùng Terraform để triển khai các tài nguyên Kubernetes sau:

    • Một Namespace tên là rocket-app
    • Một Deployment chạy image Nginx trong namespace rocket-app
    • Một Service kiểu LoadBalancer để public deployment Nginx
  • Xuất ra địa chỉ IP hoặc tên miền của LoadBalancer sau khi Terraform chạy xong.
  • Viết file README.md mô tả tất cả các bước để chạy mã Terraform, khởi tạo cụm Kubernetes, và cách xoá bỏ toàn bộ tài nguyên khi cần.

Ràng buộc bổ sung

  • Mã Terraform phải idempotent (chạy nhiều lần không sinh lỗi hoặc drift).
  • Có bình luận trong code Terraform để giải thích các quyết định kỹ thuật.

Tiêu chí đánh giá

  • Tạo cụm Kubernetes thành công.
  • Deploy đủ các tài nguyên Kubernetes được yêu cầu.
  • Đảm bảo tính idempotent.
  • Chất lượng và tổ chức mã nguồn tốt.
  • README.md đầy đủ, rõ ràng, giúp người khác hiểu cách chạy mã và huỷ tài nguyên.

7. Triển khai Istio trên Kubernetes (Junior/Middle)

Tình huống

Bạn cần tạo một dự án đơn giản sử dụng Istio để triển khai hai microservice trên một cụm Kubernetes. Mục tiêu là dùng Istio để quản lý lưu lượng truy cập giữa các dịch vụ này.

Yêu cầu trước khi bắt đầu

  • Cụm Kubernetes đã hoạt động
  • Đã cài đặt Istio vào cụm đó

Các file cần thiết

  1. service-a-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: service-a
spec:
  replicas: 1
  selector:
    matchLabels:
      app: service-a
  template:
    metadata:
      labels:
        app: service-a
    spec:
      containers:
        - name: service-a
          image: nginx
          ports:
            - containerPort: 80
  1. service-b-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: service-b
spec:
  replicas: 1
  selector:
    matchLabels:
      app: service-b
  template:
    metadata:
      labels:
        app: service-b
    spec:
      containers:
        - name: service-b
          image: nginx
          ports:
            - containerPort: 80

Mục tiêu

  • Viết các quy tắc định tuyến bằng Istio để điều hướng traffic giữa hai service.
  • Kiểm tra việc định tuyến bằng cách truy cập endpoint nhiều lần và quan sát việc phân phối lưu lượng theo tỷ lệ (weight) bạn đã cấu hình trong VirtualService.

8. Kỹ thuật Chaos Engineering (Upper-Middle)

Tình huống

Bạn là kỹ sư chính chịu trách nhiệm về tính ổn định và khả năng phục hồi (resilience) của một hệ thống microservice được triển khai trên AWS. Để đảm bảo rằng hệ thống có thể xử lý lỗi một cách duyên dáng (gracefully), bạn quyết định chủ động tạo ra sự cố (chaos) trong hệ thống bằng cách sử dụng công cụ Chaos Monkey.

Mục tiêu

  • Cài đặt và cấu hình Chaos Monkey trên một EC2 instance.
  • Sử dụng Chaos Monkey để tự động ngắt (terminate) các instance thuộc một Auto Scaling Group (ASG) cụ thể.
  • Giám sát hành vi của hệ thống khi xảy ra ngắt máy bằng AWS CloudWatch.

Ràng buộc

  • Giả định bạn có toàn quyền truy cập AWS (full access).
  • Có thể dùng bất kỳ ngôn ngữ lập trình hoặc script nào bạn quen thuộc.

Các gợi ý nhanh

1

Gợi ý:

  • Sử dụng Redis với StatefulSet, PersistentVolumeClaim, và Headless Service, tất cả trong namespace mrzero.
  • Tạo alias cho execute

2

Gợi ý:

  • Dùng tar -xzf để giải nén
  • Dùng find . -type f -exec chmod 0664 {} cho file
  • Dùng find . -type d -exec chmod 0775 {} cho thư mục
  • Dùng chown -R anonymous:no-team . để thay đổi chủ sở hữu
  • Dùng tar -czf /tmp/fixed-archive.tar.gz * để nén lại

3

Gợi ý:

  • Nếu chưa quen với kubectl create cronjob, hãy thử chạy: kubectl create cronjob --help
  • Anh em chưa biết có thể search keyword: “kubernetes create cronjob from command line”

4

Gợi ý

  • Bạn nên chia file YAML thành 2 job:

    1. build-and-test: chạy trên mọi push/PR
    2. deploy: chỉ chạy khi github.event_name == 'push' và github.ref == 'refs/heads/main'

  • Sử dụng thư viện pytest hoặc framework test có sẵn của project.

  • Việc triển khai có thể dùng:

    • scp để copy source code lên EC2
    • ssh để remote và restart service
    • Hoặc triển khai qua Elastic Beanstalk CLI, Heroku CLI, Azure CLI, v.v.

Gợi ý học tập thêm:

  • Tìm hiểu job.if, needs, env, secrets, matrix trong GitHub Actions
  • Tìm hiểu kỹ các biến môi trường tự động mà GitHub cung cấp trong mỗi run

  • Nếu dùng AWS:

    • Sử dụng AWS IAM user để tạo key
    • Gán AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY vào GitHub Secrets

5

Gợi ý

  • Bắt đầu từ đâu?

    • => Trước tiên, xác định cụ thể bạn sẽ triển khai ứng dụng mẫu từ repo nào. Nếu không có repo mẫu của công ty, bạn có thể tự tạo repo với một deployment.yaml đơn giản cho Nginx.

  • Cài đặt ArgoCD như thế nào?

    • => Gợi ý: ArgoCD có manifest chính thức cài đặt bằng kubectl apply -n argocd ..., nhưng bạn cũng có thể dùng Helm nếu quen thuộc. Hãy đọc tài liệu chính thức tại argo-cd.readthedocs.io.

  • Tạo ArgoCD Application bằng cách nào?

    • => Có 2 cách phổ biến:

    • Tạo YAML Application và apply bằng kubectl apply.

    • Hoặc truy cập giao diện Web UI của ArgoCD và khai báo ứng dụng qua đó.

  • Thay đổi gì để kiểm tra tự động deploy?

    • => Thử sửa tên Deployment, đổi image tag, thêm label, hoặc update nội dung file index.html (nếu dùng ConfigMap/volume).
    • => Theo dõi ArgoCD Web UI hoặc dùng argocd app get <app-name> để kiểm tra cập nhật.

  • Rollback hoạt động như thế nào?

    • => Gợi ý: ArgoCD có thể giữ các version trước của ứng dụng để rollback bằng nút bấm (UI) hoặc CLI (`argocd app rollback `).
    • => Hãy thử cập nhật image lên version sai, rồi rollback lại để kiểm tra.

  • Phần tài liệu cần chuẩn bị

Viết một tài liệu ngắn hoặc README.md bao gồm:

  • Từng bước bạn đã thực hiện để cài đặt ArgoCD và deploy ứng dụng.

  • Các file YAML bạn đã viết hoặc sửa.

  • Cách bạn xác thực ArgoCD đã tự động deploy khi bạn push code.

  • Cách bạn thực hiện rollback.

  • Các vấn đề phát sinh (nếu có) và cách bạn giải quyết.

  • Bonus

  • Thử kết nối ArgoCD với GitHub repo dùng Webhook hoặc ArgoCD Polling, so sánh ưu nhược điểm.

  • Cấu hình ArgoCD RBAC hoặc SSO (nếu bạn muốn thử thách cao hơn).

6

Gợi ý

1. Khởi tạo Terraform project

  • Dùng terraform init, terraform fmt, terraform validate để kiểm tra cấu trúc và định dạng.
  • Chia rõ file: provider.tf, main.tf, outputs.tf, variables.tf cho dễ bảo trì.

2. Chọn cloud provider

  • Nếu mới bắt đầu: chọn AWS với EKS vì Terraform hỗ trợ tốt module EKS chính chủ (terraform-aws-eks).
  • Đừng cố tự viết từng resource EKS thủ công => dùng module sẽ dễ hơn rất nhiều.

3. Viết module deploy app

  • Sau khi cụm K8s lên rồi, sử dụng kubernetes provider trong Terraform (đừng quay lại viết YAML).
  • Viết resource kubernetes_namespace, kubernetes_deployment, kubernetes_service.

Gợi ý: Phải dùng kubernetes provider đúng kubeconfig của cluster vừa tạo (dùng local_file, aws_eks_cluster_auth, etc.).

4. Output thông tin

  • Dùng output block để in ra IP hoặc DNS name từ Service kiểu LoadBalancer.

5. Đảm bảo idempotent

  • Luôn test lại bằng terraform plan 2-3 lần để xem có bị drift hoặc tainted không.
  • Tránh hardcode => dùng variable, locals, output rõ ràng.

6. README.md rõ ràng

  • Gợi ý nội dung:

    • Giới thiệu bài toán.
    • Cách cấu hình cloud credential.
    • Cách chạy terraform apply, validate.
    • Cách destroy cụm (terraform destroy).
    • Liệt kê output mong đợi.

7

Gợi ý

  1. Cài đặt Istio

    • Gợi ý: Sử dụng Istioctl hoặc Helm để cài.
    • Ghi nhớ: Đảm bảo namespace istio-system có đầy đủ Pod chạy ổn định.

  2. Triển khai hai service

    • Dùng file service-a-deployment.yaml và service-b-deployment.yaml như đã cho.
    • Gợi ý thêm: Cần tạo thêm Service object cho từng deployment.

  3. Thêm sidecar injection

    • Cân nhắc: Có bật chế độ tự động inject Envoy sidecar vào các Pod không?
    • Gợi ý: Label namespace để Istio inject sidecar nếu cần.

  4. Tạo Gateway, VirtualService và DestinationRule

    • Mục tiêu: Định tuyến một lượng traffic đến service-a, phần còn lại đến service-b.
    • Gợi ý: Có thể bắt đầu với match theo URI hoặc gửi toàn bộ đến một host cụ thể và chia đều traffic.

  5. Kiểm tra

    • Dùng curl hoặc một Pod tạm để gửi request nhiều lần.
    • Quan sát: Có sự thay đổi phản hồi từ service khác nhau không?

8

Gợi ý

Bước 1: Tìm hiểu và cài đặt Chaos Monkey

  • Gợi ý: Chaos Monkey gốc là phần của Netflix Simian Army, nhưng nó đã ngừng phát triển.

  • Hướng thay thế: Dùng chaos-engineering tools hiện đại như:

Bước 2: Cấu hình Chaos Monkey để terminate instance trong ASG

  • Gợi ý:

    • Xác định đúng tên Auto Scaling Group
    • Đảm bảo Chaos Monkey (hoặc công cụ tương đương) có quyền gọi API TerminateInstanceInAutoScalingGroup
    • Tạo một IAM Role với quyền đủ mạnh, đính vào EC2 đang chạy Chaos Monkey

Bước 3: Cấu hình CloudWatch để giám sát

  • Gợi ý:

    • Tạo Alarm theo CPUUtilization, UnhealthyInstanceCount, NumberOfInstances
    • Gắn tag cho các alert để dễ lọc theo môi trường thử nghiệm
    • Có thể dùng AWS SNS để gửi alert về Slack hoặc Email

Bước 4: Ghi chú lại các quan sát khi thử nghiệm chaos

  • Cần trả lời các câu hỏi sau:

    • Hệ thống có tự phục hồi đúng như kỳ vọng không?
    • Có downtime hay lỗi dịch vụ nào không?
    • Các cảnh báo có được kích hoạt đúng lúc?
Article Thumbnail
Article Thumbnail
Datadog Webinar: Modernize AWS Logs at Scale

Sự kiện đang hiện hành

Nội dung nổi bật

Bài viết khác

Chia sẻ bài viết:
Theo dõi
Thông báo của
0 Góp ý
Được bỏ phiếu nhiều nhất
Mới nhất Cũ nhất
Phản hồi nội tuyến
Xem tất cả bình luận