빡쎄 이뤄 낸다 는건

Simple is the best 제가 생각 했을 땐 정말 운영이란 정말 Simple is the best 라고 생각 됩니다. 복잡하기만 기능들을 많아지겠지만 그에 비해 관리만 힘들어질 뿐이죠 argo workflow directory 구조 저는 디렉터리 구조를 아래 처럼 가져가고 있습니다. 이유는 적절한 추상화를 통해 최소한의 권한 분리 ( 프로젝트 별 )을 진행 하기 위해서 아래 같은 구조를 가져 갔습니다. 위 디랙터리를 가져간 이유는 ClusterWorflowTemplates의 사용에 대해서 신경 쓰지고 가져다 쓰고 싶다 였습니다. 따로 WorflowTemplates나 CronWorflow 같은 것들도 나눌 수 있지만 해당 프로젝트에서 통합적으로 관리 하면 더 편할 것 같아서 적절한 추상화를 통해 ..

다양한 CI/CD 들을 만들 수 있는 툴이지만 단순 CI/CD 만 사용하기엔 정말 아까운 툴인 것 같습니다 ! 어떤 자동화 시스템을 개발하여 관리하기 위해서는 많은 인력이 투입되서 개발을 진행해야 하며, 실행하고 배포를 해야하고 또 잘 작동하는지 모니터링을 해야하는 여러 리소스들이 많이 들어갑니다. 하지만 argo workflow는 여러가지 템플릿만 개발해 두면 "개발,실행,배포"가 동시에 이뤄질 수 있다는 장점 ! 즉, 손쉽게 자동화 기능을 구현가능 합니다. 예시로 저희는 지금 devop management 란 API 서버를 개발해서 자동화를 위해 운영중입니다. 하지만 몇 백대의 devop management 란 API 서버를 어떻게 배포를 할 것인지 어떻게 상태 체크를 할 것인지 앞길이 쫌 막막하긴 ..

prometheus service discover 을 이용해 동적으로 EC2의 메트릭을 수집하기 제목이 쫌 장대하게 긴데 결론적으로 말하자면 오토스케일링 그룹에서 유동적으로 EC2가 늘어 나는걸 수집하고 싶다 ! 라고 생각해서 검색하다보니 service discover라는 것이 있어서 함쓰윽 공신문서 돌아보니 내가 원하는 기능이 딱 있어서 바로 적용을 시켜 봤다. 여짓까지 prometheus 수집을 IP와 포트를 바탕으로 EC2 기존 수집을 했는데 ( 귀찮지만 레이블 설정을 이쁘게 하려고 ) MSA 로 넘어가고 쿠버네티스로 넘어가고 있는 과도기라 바쁘기도 하고 모든 서버의 태깅을 해서 관리를 하는 것도 괜찮겠다 란 생각이 들었다. 잡담이 길어졌는데 한마디로 EC2의 tag를 이용해서 관리가 가능했던 것입..

WorkflowTemplate 란? WorkflowTemplate은 Argo Workflow에서 재사용 가능한 워크플로우 정의의 모음입니다. 일반 워크플로우와 비슷하지만, WorkflowTemplate은 독립적으로 실행할 수 없으며 다른 워크플로우에서 참조되어 사용됩니다. WorkflowTemplate의 주요 목적은 코드 재사용 및 모듈화로, 여러 워크플로우에서 공통적으로 사용되는 템플릿을 중앙 집중식으로 관리할 수 있습니다. WorkflowTemplate 사용의 장점은 다음과 같습니다. 코드 재사용: 워크플로우 간에 중복되는 작업을 줄이고 공통 템플릿을 통합하여 관리할 수 있습니다. 이로 인해 워크플로우 정의를 간소화하고 유지 관리를 용이하게 할 수 있습니다. 모듈화: 각 WorkflowTemplate..

Workflow 란 ... Workflow는 일련의 작업들이 서로 연결되어 순차적, 병렬, 또는 복잡한 종속성 구조를 가진 형태로 실행되는 프로세스이며, 다음과 같은 특성을 같습니다. 자동화: 워크플로우는 일련의 작업들을 자동으로 실행할 수 있도록 구성되어 있습니다. 이를 통해 오류 가능성이 높은 수동 작업을 최소화하고, 작업의 정확성과 일관성을 높일 수 있습니다. 재사용성: 워크플로우는 재사용 가능한 작업 또는 작업 그룹을 정의할 수 있습니다. 이를 통해 코드 중복을 줄이고, 워크플로우 구성의 유지 관리를 용이하게 할 수 있습니다. 모듈화: 워크플로우는 작업을 작은, 독립적인 모듈로 나눌 수 있습니다. 이를 통해 개발 및 유지 관리에 드는 시간과 노력을 줄일 수 있으며, 각 작업의 책임을 명확하게 구분..

UI를 가진 오픈 소스를 사용할 때마다 드는 생각이 아이디 발급하는 것 만큼 귀찮고 의미 없는 작업이란 생각에 해당 부분을 대부분 오픈소스들에 goolge Oauth를 적용하여 이용하는 중입니다. argocd 같은 경우 google Oauth를 이용해 이용하고 있고 argo workflows 역시 SSO 인증이 된다고 나와 있으나 이게 사알짝 BRAC와 얽혀 있어서 인증이 되고 이용하는데 있어서 설정해 줘야 할 부분들이 있기에 알아 보도록 하겠습니다. 설치는 helm을 이용하여 argocd 로 배포할 예정입니다. 참조 : https://argoproj.github.io/argo-workflows/argo-server-sso/ 아래는 helm 차트에 나와있는 SSO 적용 방법입니다. ( 필자는 다써두고 중..

CI/CD 를 구축하면서 github Action 만 신경 쓰다가 결국 github가 장애가 발생하는 경우가 종종 생기곤 할 때 곤란한 부분이 있다고 생각했었고 실제로도 그런 경우를 겪기도 해서 유사시에 수동으로 빌드할 수 있는 젠킨스와 같은 중앙의 툴이 있었으면 좋겠다고 생각 했던 와중 argo workerflow 라는 툴이 눈에 들어오게 되었습니다. argo 측에서 개발 하고 있는 오픈 소스로 설명 을 읽어보니 airflow와 비슷한 기능을 수행하는 오픈소스 였으나, 여러가지 기능이 개발(argo-events)되면서 CI 뿐만 아니라 API 게이트 웨이 같은 기능도 있어 서버리스 기능 까지 구현 할 수 있지 않을까? 란 생각이 들기 시작하면서 빠지게 된 것 같습니다. 무엇보다 Dags 및 크론 같은 ..

Istio를 설치하고 관리하는 방법은 여러 가지가 있습니다. 그러나 일반적으로는 Helm 또는 istioctl 중 하나를 사용하여 설치하고 관리하는 것이 가장 일반적인 방법입니다. Helm은 Kubernetes에서 애플리케이션을 배포하기 위한 패키지 관리자이며, Istio를 설치하고 관리하는 데 사용할 수 있습니다. Istio를 Helm으로 설치하면 Istio의 모든 구성 요소를 한 번에 설치할 수 있으며, 보다 쉬운 관리가 가능합니다. 또한 Helm chart를 사용하여 Istio를 업그레이드하거나 롤백하는 것도 쉬워집니다. 반면에 istioctl은 Istio의 CLI 도구로서, Istio의 다양한 기능을 관리하는 데 사용됩니다. istioctl을 사용하면 Istio를 좀 더 직접적으로 관리할 수 있습..

들어가기 앞서 ... 쿠버네티스를 하는데 왜 서비스 메시를 알아야하지? 라는 의문점을 갖으실 수 있습니다. 실제 쿠버네티스만 운영하기 위해서는 모르셔도 상관은 없습니다. 하지만 쿠버네티스는 MSA 패턴으로 나온 모델이고 이에 MSA의 고질적인 문제들도 함께 담고 있습니다. 그 고질적인 문제를 해결 하기 위해 나온 것들이 여러 있는데 그 중 하나가 서비스 메시이며, 고도화된 MSA 패턴을 운영 하기 위해서는 필수적으로 학습되어야 생각되서 길게 잡았습니다. 서비스 메시가 필요한 이유 지금까지 실습해오며 쿠버네티스 오브젝트인 서비스(service)를 대량으로 운영하지 않았습니다. 하지만 이 service들이 많이 늘어나게 된다면 이들 간에 잦은 트랜잭션 때문에 낮은 지연과 상당한 대역폭이 필요할 수도 있을 겁..

네트워크 포트의 버퍼 크기 맞추기 위 그림과 같이 스위치에서 서버로 전달된 패킷은 -1차로 네트워크 카드 내 Ring buffer에 보관되며 -2차로 커널의 Socket RCV Buffer로 이동한다. 이후엔 유저 어플리케이션의 read 함수를 통해 전달 이러 하여 커널의 Socket RCV Buffer가 괜찮더라도 Ring Buffer size가 적으면 병목형상이 발생 할 수 있다. 그렇기 때문에 상한 사이즈인 Maximum 값으로 값을 설정해주는 것을 권장하며 Linux 상에서 NIC의 Ring Buffer(Current, Maximum) 값은 ethtool -g 명령어를 통해 확인 가능하다. 지금 우리 서버에 bond1로 묶인 포트들이다. 단순 RR로 묶인거라 여기서 설정해주면 bond1에서도 그대..