본문으로 건너뛰기

마치며

지금까지 Argo에 대해 간단하게 학습해 보았습니다.
Argo Workflows로 이미지를 빌드한 다음 변경된 이미지를 Helm chart에 반영하도록 하고, Argo Events로 이벤트를 감지하여 Workflow를 실행하도록 하였으며, 마지막으로 Argo CD로 Helm chart를 연결하여 리소스가 자동으로 배포/관리되도록 하였습니다.

개선해야 할 점

꽤 많은 것을 했지만, 개선할 점도 있습니다.

  • 현재 서비스가 외부에 공개되지 않은 상태여서, MinIO로 수동 이벤트를 발생시켰습니다. 실제 사용 시에는 Git에 직접 연결하여 이벤트를 제어하게 될 것입니다.
  • 테스트 환경이었기 때문에 일부 권한을 부여할 때 전체 권한을 부여하거나, 사전에 정의된 Role, ClusterRole 등을 재활용했습니다. 보안 옵션도 거의 설정하지 않았습니다. 실제 사용 시에는 권한과 보안 부분을 많이 고려해야 할 것입니다.
  • 서비스 규모에 따라, Scaling에 대한 고민도 필요합니다. 특히 일반적인 세팅으로 Argo를 사용하는 것은 대규모 서비스에 적합하지 않습니다. 저도 실제 업무 환경에서 Argo CD에 등록된 Repository와 Application이 너무 많아 특정 UI로 진입할 경우 Argo CD가 다운되는 이슈를 경험했었습니다. 이 경우 Argo에 할당할 자원, 메모리 할당, 관리 정책 등 여러 요소를 알맞게 조정해야 할 것입니다.
    이 부분은 저도 경험해 보지 못한 부분이므로, Argo CD에 대해 참고할 만한 영상만 하나 남겨두고 넘어가겠습니다.
    https://youtu.be/H3T-Nkxdywg

무한한 가능성

앞에서 개선할 점들을 말했지만, 이 프로젝트에서 한 걸음 더 나아갈 수도 있습니다.

  • 외부에 서비스를 오픈할 수 있습니다. 이미 MetalLB와 Ingress NGINX Controller를 설치해 두었기 때문에, 공용 네트워크와 도메인 등을 추가로 설정하면 서비스 개방이 가능합니다! 물론 보안 쪽은 잘 생각해야겠지요.
  • 사실 여기서는 Multi-node 클러스터를 구성만 해 두고 제대로 활용하지 않았습니다. 하지만 더 큰 서비스에서 이를 기반으로 효율적인 K8S 유지관리가 가능할 것입니다.
  • 여기서는 CI/CD를 구현했지만, Argo는 CI/CD 외에도 다른 많은 곳에 활용 가능합니다. 어떻게 활용하느냐는 여러분의 몫입니다.
  • 여기서 사용된 Tool들은 원하는 대로 변경하고, 추가하셔도 됩니다.
    • Docker Hub 대신 개인 이미지 저장소를 사용하고 싶다면 Harbor를 사용해도 됩니다.
    • Github 대신 Gitlab 등의 다른 플랫폼, 또는 Private repository를 사용해도 됩니다.
    • 꼭 Argo를 써야 하는 것도 아닙니다.
      상황에 따라 Apache Airflow 등의 다른 도구를 사용할 수도 있을 것입니다.

첫 문서를 작업하며

처음에는 평소처럼 혼자서 조용히 실습하고, 정리한 다음 끝내려 했는데, 문서화를 하기로 결정하고 여기까지 왔습니다. 생각보다 어려운 작업이라는 것을 많이 느꼈고, 돌이켜 보면 실습 기간보다 문장을 고민하고 reference를 찾던 시간이 더 많았던 것 같기도 합니다. 이 뒤에도 당분간 영어 번역을 포함해 전체적인 검수를 하면서 완성도를 높이려고 합니다.
그래도 첫 문서화 프로젝트이기에 아직 부족한 점이 많습니다. 너그럽게 이해해 주시고, 필요하다면 많은 피드백 부탁드립니다. 감사합니다.

2024, HU-Lee.