Tải rootAVD về máy

git clone https://gitlab.com/newbit/rootAVD.git hoặc tải nhanh tại đây rootAVD

Tạo 1 máy ảo Android

Mở Virtual Device Manager lên

Tạo 1 máy ảo Android (ở đây tôi sẽ dùng Pixel 4)

Chọn phiên bản Android (tôi sẽ dùng phiên bản Android 12.0 - API 31)

Chạy máy ảo vừa tạo lên

Root máy ảo

Truy cập vào thư mục chứa rootAVD vừa tải về

Sau đó mở CMD lên, gõ lệnh rootAVD.bat ListAllAVDs

Chạy lệnh rootAVD.bat system-images\android-31\google_apis_playstore\x86_64\ramdisk.img để root AVD

Chờ tới khi root thành công

Chạy lại Android với Cold Boot

Kiểm tra nếu có ứng dụng Magisk là thành công

Vào Settings bật Zygisk nếu chưa được bật

Sau đó reboot lại để cấu hình được cập nhật

Bật Zygisk thành công

Cài Burp Suite CA để intercept HTTPS

Tải Burp Suite CA về máy, mở Burp Suite Browser lên và nhập URL http://burp. Bấm vào CA Certificate để tải cert về máy

Tiếp theo tải AlwaysTrustUserCerts tại đường dẫn https://github.com/NVISOsecurity/AlwaysTrustUserCerts/releases/latest.

Ở đây tôi sẽ dùng phiên bản AlwaysTrustUserCerts_v1.3

Đẩy file lên máy ảo android bằng lệnh sau:

adb push cacert.der /sdcard

adb push AlwaysTrustUserCerts_v1.3.zip /sdcard

Để cài đặt CA Certificate ta cần vào cài đặt như sau: Settings → Security → Encryption & credentials → Install a certificate → chọn CA Certificate

Để kiểm tra cài cert thành công hay không ta vào: Settings → Security → Encryption & credentials → Trusted credentials → chọn tab User

Đã cài đặt cert thành công, nhưng mục tiêu là cần đẩy cái cert này sang bên System để có thể nhiều quyền hơn.

Ta cài đặt module AlwaysTrustUserCerts vào app Magisk → chọn tab Modules (dưới cùng tay phải)

Chọn file AlwaysTrustUserCerts_v1.3.zip

Sau khi cài đặt thành công thì bấm Reboot ở dưới

Kiểm tra lại module đã hiện lên chưa

Kiểm tra cert đã sang bên System chưa, ta vào: Settings → Security → Encryption & credentials → Trusted credentials → chọn tab System → kéo xuống tìm PortSwigger

Như vậy ta đã cài thành công cert ^^

Cấu hình proxy Burp Suite

Để kiểm tra xem Burp Suite đã bắt được request thành công chưa, ta cấu hình proxy như sau

Sau đó, mở trình duyệt và kiểm tra request

Bắt request thành công ^^
Tuy nhiên 1 số ứng dụng sẽ áp dụng thêm 1 số cách để ngăn chặn bắt request nên ta sẽ phải sử dụng các tools như: Frida, Objection, …

Nội dung tham khảo

Nội dung bài viết này được mình tìm hiểu, dịch, tham khảo, đúc kết và tổng hợp lại từ nhiều nguồn. Mọi người có thể xem thêm các bài viết sau:

• Root Android 12.0 API Level 31 and add BurpSuite CA Certificate

• How to Root Android Phone & Install AlwaysTrustUserCert.zip Module?

• Làm quen cùng pentest Android 😎

1. Round Robin

Round Robin là hình thức cân bằng tải đơn giản nhất, thường được cài đặt mặc định trong 1 số load balancer, trong đó mỗi máy chủ trong nhóm nhận được yêu cầu theo thứ tự luân phiên, tuần tự. Khi đến máy chủ cuối cùng, nó sẽ lặp lại máy chủ đầu tiên.

2. Least Connections

Hướng lưu lượng truy cập đến máy chủ có ít kết nối hoạt động nhất. Điều này đặc biệt hữu ích khi có các phiên có độ dài và nhu cầu khác nhau.

3. Weighted Round Robin

Tương tự như Round Robin nhưng chỉ định trọng số cho các máy chủ dựa trên dung lượng của chúng, hướng nhiều lưu lượng truy cập hơn đến các máy chủ mạnh hơn.

4. Weighted Least Connections

Kết hợp các lợi ích của Least Connections và Weighted Round Robin, xem xét cả tải và dung lượng của máy chủ.

5. IP Hash

Sử dụng địa chỉ IP của khách hàng để chuyển các yêu cầu của họ đến cùng một máy chủ một cách nhất quán.

6. Least Response Time

Chuyển yêu cầu đến máy chủ có thời gian phản hồi nhanh nhất và số lượng kết nối hoạt động thấp nhất.

7. Random

Gửi yêu cầu đến máy chủ một cách ngẫu nhiên.

8. Least Bandwidth

Gửi yêu cầu đến máy chủ tiêu tốn ít băng thông mạng nhất.

Nội dung tham khảo

Nội dung bài viết này được mình tìm hiểu, dịch, tham khảo, đúc kết và tổng hợp lại từ nhiều nguồn. Mọi người có thể xem thêm các bài viết sau:

• Prof. C Murwamuila - 8 Essential Load Balancing Algorithms

• Design Gurus

• The Essential Guide to Load Balancing Strategies and Techniques | by Hayk Simonyan | Level Up Coding (gitconnected.com)

Cluster Management

1. Display endpoint details for the cluster’s master and services.

   kubectl cluster-info
   

2. Show the Kubernetes version that is active on the server and client

   kubectl version
   

3. Get the cluster’s configuration

   kubectl config view
   

4. List the available API resources

   kubectl api-resources
   

5. List everything

   kubectl get all --all-namespaces
   

Node Management

1. List the nodes

   kubectl get node
   

2. Update the taints on nodes

   kubectl taint node <node_name>
   

3. Delete a node

   kubectl delete node <node_name>
   

Pod Management

1. List pods

   kubectl get pod
   

2. Delete a pod

   kubectl delete pod <pod_name>
   

3. See detailed state of a pods

   kubectl describe pod <pod_name>
   

4. Create a pod

   kubectl create pod <pod_name>
   

5. Run a command for a container inside a pod

   kubectl exec <pod_name> -c <container_name> <command>
   

6. Get interactive shell on a pod

   kubectl exec -it <pod_name> /bin/sh
   

7. See resource usage (CPU/Memory/Storage) for pods

   kubectl top pod
   

8. Add/update the annotations of a pod

   kubectl annotate pod <pod_name> <annotation>
   

9. Add/update the label of a pod

   kubectl label pod <pod_name>
   

Replication Controllers

1. View the list of replication controllers

   kubectl get rc
   

2. View the list of replication controllers by namespace

   kubectl get rc --namespace="<namespace_name>"
   

3. Scale a ReplicaSet

   kubectl scale --replicas=<expected_replica_num> replicaset <name>
   

Deployment Management

1. List the deployments

   kubectl get deployment
   

2. Show the precise status of single or multiple deployments.

   kubectl describe deployment <deployment_name>
   

3. Edit and update the deployment.

   kubectl edit deployment <deployment_name>
   

4. Create a new deployment

   kubectl create deployment <deployment_name>
   

5. Delete a deployment

   kubectl delete deployment <deployment_name>
   

6. Check the rollout status of a deployment

   kubectl rollout status deployment <deployment_name>
   

7. Display Resource usage (CPU/Memory/Storage) for nodes

   kubectl top node
   

8. See resource allocation per node

   kubectl describe nodes | grep Allocated -A 5
   

9. List the pods running on a node

   kubectl get pods -o wide | grep <node_name>
   

10. To annotate a node

    kubectl annotate node <node_name>
    

11. Add or update the labels of a node

    kubectl label nodes <your-node-name> <label>
    

12. Scale a Deployment

    kubectl scale deployment <deployment-name> --replicas=<number-of-replicas>
    

Secrets

1. Create a secret

   kubectl create secret <name>
   

2. List secrets

   kubectl get secrets
   

3. View details about secrets

   kubectl describe secrets <name>
   

4. Delete a secret

   kubectl delete secret <secret_name>
   

Services

1. List the services

   kubectl get services
   

2. View the detailed state of a service

   kubectl describe services <name>
   

3. Expose a replication controller, deployment or pod as a new Kubernetes service

   kubectl expose deployment [deployment_name]
   

4. Edit/update the definition of a service

   kubectl edit service <name>
   

Common Options

Commands in Kubectl can include optional flags. Here are a few examples of the most popular and helpful ones.

1. –o Format of output. (Suppose you wanted to list all of the pods in ps output format with additional information.)

   kubectl get pods -o wide
   

2. Create any resource(pod/replicaset/deployment, etc) using a yaml/json file.

   kubectl apply -f <xyz.yaml>
   

Nội dung tham khảo

Nội dung bài viết này được mình tìm hiểu, tham khảo, đúc kết và tổng hợp lại từ nhiều nguồn. Mọi người có thể xem thêm các bài viết sau:

• K21Academy - KUBERNETES CHEATSHEET

Tất nhiên cái gì cũng có cái giá của nó ^^. Mình cũng đã từng gặp trường hợp như vậy khi triển khai dự án ở công ty, mình dựng 1 server GitHub Action self-hosted để chạy CI (Continuous Innovation) build image mới nhất từ Repo mỗi khi đẩy code vào nhánh prod, staging hoặc dev.

Truy tìm giấu vết

Quá trình này hoạt động cũng được gọi là ổn định cho đến khi 1 vấn đề xảy ra 😒

Error: no space left on device

Lối bên trên chỉ mang tính chất minh hoạ, nhưng đại loại là lỗi trả về có dạng no space left on device. Ngay lập tức mình kết nối vào server để xem tình hình ra sao. Sau đó chạy lệnh df để kiểm tra disk còn bao nhiêu % ổ đĩa trống.

ubuntu@builder:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
tmpfs           791M  3.3M  787M   1% /run
/dev/sda2        98G   98G   0     99% /
tmpfs           3.9G     0  3.9G   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           791M  4.0K  791M   1% /run/user/1000

(Kết quả đã được mình chế cháo lại 😁, nhưng đại loại là sẽ có dạng như vậy) Nhìn kết quả bên trên chắc các bạn cũng sẽ thấy /dev/sda2 đang đầy 99%. khi đầy thì cột Used sẽ cao, Avail sẽ thấp và cột Use% sẽ hiển thị % sử dụng ổ đĩa

Tiếp tục kiểm tra kích thước của từng thư mục từ thư mục root

sudo du -h --max-depth 1 / | sort -gr

Thấy thư mục /var lớn nhất, check tiếp bên trong thư mục đó.

sudo du -h --max-depth 1 /var | sort -gr

Tiếp tục với thư mục /var/lib thì tôi tìm ra thư mục /var/lib/docker nặng nhất, cụ thể lúc đấy khoảng 80GB.

ubuntu@builder:~$ sudo du -h --max-depth 1 /var/lib/docker
4.0K    /var/lib/docker/runtimes
40G     /var/lib/docker/overlay2
148K    /var/lib/docker/volumes
4.9M    /var/lib/docker/containers
4.0K    /var/lib/docker/tmp
4.0K    /var/lib/docker/swarm
152K    /var/lib/docker/network
56M     /var/lib/docker/image
39M     /var/lib/docker/buildkit
16K     /var/lib/docker/plugins
40G     /var/lib/docker

Ok vậy đã tìm được nguyên nhân là do docker, bước tiếp theo là xem cái gì dọn dẹp đươc thì dọn dẹp. Các thứ mình nghĩ có thể dọn dẹp được bao gồm:

• Log của các container

• Các volume không còn được sử dụng

• Các container đã stopped

• Các image mà không được sử dụng

• Build cache

Tìm được các thứ cần dọn dẹp rồi thì chúng ta bắt đầu dọn dẹp thôi.

Xoá các volume không sử dụng nữa

Câu lệnh dọn dẹp các volume mà không được sử dụng nữa.

docker volume prune -f

Xoá các image không sử dụng nữa

Câu lệnh dọn dẹp các image mà không được sử dụng nữa.

docker image prune -a -f

Xoá các container không sử dụng nữa

Câu lệnh dọn dẹp các container mà không được sử dụng nữa.

docker container prune -f

Xoá các builder không sử dụng nữa

Câu lệnh dọn dẹp các builder mà không được sử dụng nữa. (Server builder của mình nặng nhất phần này, vì phải build image liên tục dẫn tới cache làm đầy ổ cứng)

docker builder prune -a -f

Câu lệnh giúp dọn dẹp nhanh chóng system prune

Phiên bản sau này của docker có lệnh docker system prune sẽ tự động làm kha khá các việc dọn dẹp cho chúng ta.

ubuntu@builder:~$ docker system prune
WARNING! This will remove:
  - all stopped containers
  - all networks not used by at least one container
  - all dangling images
  - all dangling build cache

Are you sure you want to continue? [y/N] y
Deleted Networks:
docker-network_default
Deleted build cache objects:
98jlfzkgw1hjfdk22sd5460x5
3o8xbgqhl6e49n3illj8fenid
o692cdjs4pm8ni4l4rg8v4hpw
pobyjug26w7kddhf68st2sj5t
p3imtyiehrh0pqfptsyfyftaj
...
Total reclaimed space: 80.17GB

Hoặc chạy lệnh xoá tất cả

docker system prune -a -f

Xoá các container logs

Thứ chiếm dung lượng ổ đĩa tiếp theo là Docker Json Logs, mặc định khi cài Docker thì toàn bộ logs của container sẽ được Docker lưu ở thư mục /var/lib/docker/containers/\* ở dạng json, nếu ta không thường xuyên xóa logs ở thư mục này thì nó sẽ lên tới vài chục hoặc vài trăm GB.

Để xóa logs ở thư mục này ta có vài cách sau:

• Cấu hình crontab

• Dùng logrotate

• Giới hạn dung lượng logs của container

Dọn dẹp log của container, đơn giản là làm nó trống trơn. (Sử dụng quyền root nếu bị lỗi Permission denied )

Xóa thủ công với crontab

sudo sh -c "truncate -s 0 /var/lib/docker/containers/*/*-json.log"

Cấu hình crontab:

# daily
sudo -s

cat <<EOF > /etc/cron.daily/clear-container-logs
#!/bin/sh
truncate -s 0 /var/lib/docker/containers/**/*-json.log
EOF

chmod +x /etc/cron.daily/clear-container-logs

Tự động với logrotate

Nếu bạn muốn giữ lại logs thì có thể dùng logrotate để tự động giảm dung lượng logs của Docker.

Hầu hết các Linux Distro đều cài sẵn logrotate, cấu hình logrotate cho tệp tin logs của Docker rất đơn giản, ta tạo tệp tin logrotate-container ở thư mục /etc/logrotate.d và dán cấu hình ở dưới vào:

/var/lib/docker/containers/*/*.log {
  rotate 7
  daily
  compress
  missingok
  delaycompress
  copytruncate
}

Chạy thử:

logrotate -fv /etc/logrotate.d/logrotate-container

Măc định logrotate có sẵn crontab nằm ở thư mục /etc/cron.daily để chạy logrotate hằng ngày nên ta không cần phải cấu hình crontab thêm.

Giới hạn dung lượng logs của container

Từ phiên bản 1.8 trở đi thì Docker có sẵn chức năng logrotate cho json logs. Khi chạy container ta thêm vào thuộc tính --log-opt vào để giới hạn dung lượng logs của container.

docker run --log-driver json-file --log-opt max-size=10m --log-opt max-file=5 nginx

Trong đó:

• --log-driver=json-file: Đặt log driver cho container là json-file.

• --log-opt max-size=10m: Giới hạn kích thước tối đa của mỗi tập tin log là 10 megabytes. Bạn có thể thay đổi giá trị theo nhu cầu của mình.

• --log-opt max-file=5: Giới hạn số lượng tập tin log tối đa là 5. Khi số lượng tập tin vượt quá giới hạn, các tập tin cũ hơn sẽ bị ghi đè. Bạn có thể thay đổi giá trị theo nhu cầu của mình.

Nếu bạn đang chạy một container đang hoạt động, bạn có thể thay đổi cấu hình log driver bằng cách sử dụng lệnh docker update

docker update --log-opt max-size=10m --log-opt max-file=5 <container_id>

Nếu ta cần cấu hình cho toàn bộ container thì thêm cấu hình sau vào daemon.json, nằm ở thư mục /etc/docker/ trên Linux và ở thư mục C:\ProgramData\docker\config\ trên Windows.

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

Kết luận

Trên đây là 1 số cách để tránh và khắc phục khi ổ đĩa bị đầy trong quá trình học tập và sử dụng Docker. Cách khắc phục tuy đơn giản nhưng vấn đề này rất quan trọng nên các bạn hãy cẩn thận chọn cách phù hợp để cấu hình cho máy chủ của mình nhé ^^.

Nội dung tham khảo

Nội dung bài viết này được mình tìm hiểu, tham khảo, đúc kết và tổng hợp lại từ nhiều nguồn. Mọi người có thể xem thêm các bài viết sau:

• Quân Huỳnh (devopsvn) - Làm thế nào để tránh ổ đĩa bị đầy khi xài Docker?

• Nguyen Minh Tuan - Hết dung lượng disk do chạy Docker trong thời gian dài

• elroydevops - Những nguyên nhân gây ra đầy ổ đĩa khi sử dụng docker?

• Docker: How to clear the logs properly for a Docker container?