#7 Lạc lối nửa năm chỉ vì… biến môi trường (và cái kết không ai ngờ tới)

Đây là một phần trong series mình chia sẻ về những gì mình đã làm khi xây dựng và vận hành hạ tầng backend trên AWS cho công ty. Không phải là best practice hoàn hảo, cũng không phải kiến thức quá cao siêu. Chỉ đơn giản là những gì mình đã học được, thử nghiệm và áp dụng trong quá trình làm việc hằng ngày.

Biến môi trường là thứ không thể thiếu trong bất kỳ ứng dụng nào hiện tại, dù là lớn hay nhỏ, không ít thì nhiều, ai cũng phải đụng tới. Ừ thì mọi người nói cái này dễ mà, lưu ở chỗ bí mật là được, mấy cái best practice thì ai cũng thuộc làu cả rồi. Thế nhưng mất khoảng nửa năm, mình đã bị lạc lối, không tìm ra giải pháp.

Vấn đề của mình

Qua bài viết trước, mọi người đã biết, mình deploy các microservice qua ECS(Aws), mỗi service sẽ có task definition, nơi danh sách biến môi trường và sẽ được mapping tới Parameter Store va Secret Manager, 2 services để lưu thông tin của biến môi trường hiệu quả trong Aws. Để lưu thì khá ok nhưng để quản lý biến môi trường một cách trực quan, để các thành viên trong Team có thể thêm, xoá sửa một cách dễ dàng thì không nhé. Bạn cần có những hiểu biết nhất định về Cloud, phân quyền IAM, trách nhiệm khi có lỗi cần rollback …

Nhanh trí, mình liền tạo một project chỉ dành riêng cho biến môi trường của tất cả các services, bao gồm biến thường và biến bí mật, muốn chỉnh sửa chỉ cần làm ở đây là đủ. Mình đã thiết lập IaC ( Terraform) cho dự án, quá trình đẩy code lên Parameter Store với SecretManager quá dễ dàng. Nhưng vấn đề làm mình đau đầu là:

Team mình sử dụng github, không phải là self host nhé, các project đều ở chế độ private, mà mọi người biết rồi đấy, push biến môi trường lên github là hành động gần như là tự sát. Mỗi giây, đều có các tool scan secret trên tất cả các repos github, kể cả private.

Project vẫn nằm trong máy mình, không lẽ mỗi lần các bạn khác muốn thêm, xoá, sửa lại phải copy code sang hay sao.

Ở nơi trước kia mình từng làm thì mọi thứ rất đơn giản, họ đã self host gitlab registry, mọi thứ đều là private, nên họ push trực tiếp dự án chứa biến môi trường lên rồi thiết lập pipeline luôn cho nó, thật dễ dàng.

Giải pháp không bất ngờ

Có thể mọi người không tin, mình mất gần nửa năm để suy nghĩ tới vấn đề này. Rất nhiều ý tưởng được nghĩ ra, như trước khi đẩy lên github thì mã hoá lại, về thì giải mã ra các kiểu. Nhưng sự thực là quá phức tạp và không hiệu quả. Mục tiêu của mình trong tất cả các giải pháp nên là đơn giản nhất có thể, dev đã khổ quá rồi, đừng làm dự phức tạp một vấn đề vì khi đó, mọi thứ sẽ càng khó bảo trì và dễ lỗi. Không ai hiểu logic đó và thực hiện nó ngoài bạn.

Giải pháp của mình thực ra cũng đã nghĩ đến từ lâu nhưng tại thời điểm đó thì điều kiện lại không cho phép( đúng người sai thời điểm, haha). Aws CodeCommit về cơ bản giống như github, mọi thao tác với git đều có thể làm giống với CodeCommit. Thời điểm mình nghĩ tới phương án lúc đó thì service này của Aws đang không cho tạo repo mới ( từ năm 2024 thì phải), thế nên ý định này đành bị gác lại. Bẵng đi một thời gian, mình vẫn chưa tìm ra được giải pháp cho vấn đề biến môi trường, khi đang lướt facebook (sự kiện Aws: ReInvent 2025) thì thấy tin là CodeCommit sẽ được Aws cho tạo repo mới trở lại. Không chần chừ, mình bắt tay vào làm luôn (không lỡ lại bị khoá thì sao, haha).

CodeCommit được bảo vệ trong tài khoản Aws, nhiều lớp bảo mật hơn github. Mình cũng thiết lập quy trình CI/CD luôn cho dự án này với CodeBuild và CodePipeline. Sorry Aws, nhưng mình thấy thực sự mấy cái services CI/CD của Aws mình không ưng chút nào, quá rườm rà để giải quyết những thứ mà những tool khác làm đơn giản. Nhưng không sao, chạy được là ngon rồi đã, haha.

Kết

Mọi thứ đã chạy giống như mình mong muốn dù tìm được phương án này cũng đổ mồ hôi quá lâu. Hy vọng sẽ có giải pháp tốt hơn cho vấn đề này, vì nó vẫn bị source code không được tập trung một chỗ (Github, CodeCommit). Nếu bạn có giải pháp tốt hơn, để lại tin nhắn trong phần bình luận nhé .

Bài viết này cũng được mình dịch sang tiếng Anh trên blog substack của mình.

Mình viết lại những điều này như một cách để ghi nhớ hành trình làm nghề của mình. Nếu bạn cũng đang làm backend, devops hoặc cloud, hy vọng những chia sẻ này có thể giúp bạn một chút gì đó. Còn nếu có chỗ nào mình hiểu chưa đúng, mình vẫn luôn sẵn sàng học thêm.