Làm DevOps theo phong cách Nga ngố - part 1

S** là nhà cung cấp hosting hàng đầu của khu vực Đông Âu, Mấy anh Nga Ngố , U cà na, Belarus, Serbi đều là khách ruột của công ty này.

Hiện tại S** đang hosting khoảng hơn 1K website, vài chục triệu user, nghe nói thiên địa hội cũng đặt hosting ở đây. Ngoài ra, S** cũng có hệ thống phần mềm dùng trong nội bộ công ty như source version control, log timesheet, quản lý nhân sự, số lượng nhân viên khoảng vài K người.

Vậy hệ thống của S** được build up thế nào để có thể hosting được số lượng website và khách hàng như vậy

AWS multi-account strategy

Infra của S trên AWS với khoảng 50 môi trường. Ngoài dev, stagin, prod truyền thống thì còn có training, interview, accountant… Mỗi môi trường phục vụ cho mục đích khác nhau

Đội DevOps của S** sử dụng Multi-account Landing Zone Control Tower

Khái niệm về multi-account landing zone có thể tìm kiếm trên internet, câu chuyện ở đây là cách quản lý credentials thế nào. Vì DevOps team làm việc với AWS resources bằng AWS CLI, Key/Secret lưu trong ~/.aws/credentials để authenticate. Tuy nhiên với hơn vài chục account AWS và ngày càng tăng theo thời gian thì không ai lưu credentials theo cách truyền thống. Ngoài ra, do security, những key/secret này chỉ validate trong session vài tiếng sau đó sẽ expired và phải gen lại.

Giải pháp ở đây là dùng Swich Roles

Role ở đây là tập hợp quyền gắn với cái tên nào đó ví dụ role Giám đốc thì có quyền tuyển dụng, đuổi việc nhân viên, role Trưởng phòng có quyền review nhân viên… Role sẽ gán cho 1 user nào đó.

Trên mỗi account sẽ có 1 role, ví dụ Management Role, được assume cho user của anh DevOps

Bằng cách này, anh DevOps chỉ cần lưu 1 Key/Credentials duy nhất là master account rồi từ đây anh có thể switch qua lại giữa các account bằng switch role và không cần lưu bất kì credentials nào nữa. Và session của anh chỉ tồn tại trong vòng 12 tiếng sau đó phải refresh, như vậy bảo mật 100%

Trên Terminal, anh DevOps dùng tool awsume dùng để switch qua lại giữa các role ví dụ

awsume -a <env>

tool sẽ generate ra credentials temporary để anh DevOps access vào từng AWS account

EKS

Nhờ sự phát triển của container nên website khách hàng deploy toàn bộ trên EKS, anh Dev xài tool [eksctl] (https://eksctl.io/) để provision cluster

Cluster info được lưu trong yaml file gọi là schema, kiểu thế này

---
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: cluster-1
  region: eu-north-1

nodeGroups:
  - name: ng-1
    instanceType: m5.large
    desiredCapacity: 1

cloudWatch:
    clusterLogging:
        # enable specific types of cluster control plane logs
        enableTypes: ["audit", "authenticator", "controllerManager"]
        # all supported types: "api", "audit", "authenticator", "controllerManager", "scheduler"
        # supported special values: "*" and "all"

Sau khi cluster được launch lên thì được đến đoạn deploy, quy trình là mỗi khi có khách hàng onboard

anh DevOps sẽ implement k8s manifest dùng Kustomize để deploy. Như vậy là 100 KH là 100 bộ manifest file. Câu hỏi là sao không dùng helm, rồi mỗi khách hàng xài 1 value file khác nhau. Bởi vì, khách hàng của S tả pì lù, có khách thì xài wordpress, có khách thì web java, .net … không thể có 1 bộ helm module chuẩn. Tốt nhất là tách rời ra để dễ maintain.

Wasabi backup

Thay vì lưu code trên Github thì để tiết kiệm tiền và chắc là sợ security, anh DevOps tự build một hệ thống git riêng gọi là gitea. Nhìn chung là khá cùi bắp thua xa Github nhưng được cái là rẻ tiền,

Cách deploy thì cũng khá truyền thống, không đặc biệt lắm, tuy nhiên cách backup thì có khác bọt một chút.

Các hệ thống thông thường backup RDS dưới dạng snapshot rồi export vào S3 là đủ xài. Nhưng công ty S muốn đảm bảo an toàn hơn nên backup thêm ra hệ thống lưu trữ ngoài S3 gọi là [Wasabi]

(https://console.wasabisys.com/)

Đây là hệ thống lưu trữ tương thích với S3 nhưng giá thành rẻ hơn nhiều 80%

Dữ liệu backup từ S3 được replicate ra Wasabi để lưu trữ. Trong trường hợp AWS infra bị hack mất dữ liệu, vẫn có thể restored được từ Wasabi

Đây là sơ sơ hệ thống như vậy, tuy nhiên khi đi vào hoạt động cũng mọc ra khối issue cần phải giải quyết

Phần lớn application của khách hàng là wordpress loại statefull application, deploy EKS không scaling theo kiểu tăng replicas được, nên thỉnh thoảng lượng user tăng đột biến là hết resource app lăn quay ra chết. Còn scaling node theo kiểu vertical thì tốn tiền, sếp không chịu

Quản lý task ticket thì xài Jira truyền thống, khổ nỗi nhân viên công ty không phải ai cũng rành IT, có chị làm lao công, anh thủ kho không quen xài phần mềm phức tạp, phải tạo cái web form đơn giản cho họ xài, nhưng làm sao request từ webform nó được sync vào Jira

Ông CEO thuộc loại vắt cổ chày ra nước, chắt bóp từng đồng từng hào, yêu cầu optimize cost maximum nhưng app khách hàng down vì hết resource thì lại đè team DevOps ra chửi, làm sao cho sướng?