전체 글

지나가는 생각들과 이런 저런 기술 이야기들, 차곡차곡 담아두는 곳입니다.
🥴데일리

누적 10만 방문수 감사합니다.

19년 4월 4월에 첫 포스팅을 올리고, 약 5년 만에 10만 방문수를 찍었네요. 누추한 곳에 방문해 준 귀한 분들 감사드립니다. https://newdeal123.tistory.com/2 DP-3114번 사과와 바나나 #include #include #include #include using namespace std; const int MAX_N = 1500; int N, M; //누적합보다 메모리가 2배 더소요됨 다음에 재풀이할때는 누적합 방식을 사용할것.. int cache[MAX_N + 1][MAX_N + 1]; int cacheY[MAX_N + newdeal123.tistory.com 첫 포스팅 기록 보려고 처음으로 올렸던 글을 보니 민망하네요.. 알고리즘 문제 하나 풀고 저렇게 좋아할 일이야..

🏋️‍♀️ DevOps, SRE

엔보이(envoy) 딥-다이브 (2) : 엔보이 로깅의 2가지 종류

[이전 편] - 1편: 엔보이(envoy) 딥-다이브 (1) : 엔보이가 패킷을 받아 처리하기까지 앞서 1편에서 엔보이 사이드카가 두 애플리케이션 사이에서 프록시 역할을 수행하면서 패킷을 처리하는 과정에 관해 디테일하게 설명드렸습니다. 혹시 아직 1편을 못 보신 분은 1편을 먼저 읽고 오시면 도움이 됩니다. 이번 편은 조금 쉬운 버전으로, 엔보이 로깅의 2가지 종류에 대해 알아보고 확인해 봅시다. 엔보이는 크게 2가지 종류의 로그를 표준출력으로 출력할 수 있습니다. 표준출력이라는 뜻은 kubectl log나 로키로 확인할 수 있다는 뜻입니다. 컴포넌트 로그 엔보이가 동작하기 위한 여러 컴포넌트들의 로그입니다. 이 엔보이 컴포넌트의 로그는, 엔보이를 거친 패킷들의 로그를 출력하는 것이 아님에 유의합시다. ..

🏋️‍♀️ DevOps, SRE

엔보이(envoy) 딥-다이브 (1) : 엔보이가 패킷을 받아 처리하기 까지

0. 이스티오(Istio)와 엔보이(Envoy) 최신 애플리케이션은 일반적으로 마이크로서비스의 분산 컬렉션으로 설계되며, 각 마이크로서비스 컬렉션은 개별 비즈니스 기능을 수행합니다. 서비스 메시는 애플리케이션에 추가할 수 있는 전용 인프라 계층입니다. 이를 통해 관찰 가능성, 트래픽 관리, 보안과 같은 기능을 자체 코드에 추가하지 않고도 투명하게 추가할 수 있습니다. Kubernetes 기반 시스템과 같은 분산 서비스 배포의 규모와 복잡성이 증가함에 따라 이해하고 관리하기가 더 어려워질 수 있습니다. 요구 사항에는 검색, 로드 밸런싱, 오류 복구, 메트릭 및 모니터링이 포함될 수 있습니다. 또한 서비스 메시는 A/B 테스트, 카나리아 배포, 속도 제한, 액세스 제어, 암호화 및 엔드투엔드 인증과 같은 보..

🏋️‍♀️ DevOps, SRE

Renovate bot을 사용해 argoCD로 배포한 helm 차트 버전을 체계적으로 관리해보자

최근 배포 도구 지분의 큰 축을 담당하고 있는 argoCD, 매니페스트 저장소를 활용한 gitOps 패턴 구현을 위한 배포 도구로 많은 사랑을 받고 있습니다. 그중 핵심적인 배포 패턴이 바로 헬름(helm) 차트를 argoCD로 배포하는 것이죠. 오픈소스 운영도구들도 헬름 차트를 사용해 많이 설치하는데요, karpenter,prometheus,ingress-nginx 등 정말 많습니다. 하지만 이 수십개의 운영도구들의 버전을 체계적으로 관리하는 것은 쉬운 일이 아닙니다. 매 번 수동으로 릴리즈 노트를 찾아 업데이트를 하거나, 아무 일도 없으면 아무 일이 아니다...라는 마음가짐으로 그냥 낮은 버전을 고정시켜 두는 경우도 있는데요. 이유를 굳이 설명하지 않아도, 당연하지만 좋은 행동은 아닙니다. Renov..

🥴데일리

회사 기술 블로그 첫 포스팅 해보기

입사 1주년을 맞아 회사 기술 블로그에 첫 글을 게재했습니다. 🎉 쿠버네티스에게 Github Actions 설치에 대해 묻다 Introduction 안녕하세요. 버즈빌 DevOps 팀의 엔지니어, Cade 입니다. 최근 CI/CD에서 가장 인기 있는 플랫폼 중 하나인 깃헙 액션 (Github Actions), 많이들 사용하고 계실 텐데요. 오늘은 이 깃헙 액션을 가 tech.buzzvil.com self-hosted Github Actions 설치와 운영은 이전에 여기, 개인 블로그에 올린 적이 있는데 이번엔 조금 더 고도화해 글을 더 다듬어 회사 블로그에 올렸습니다. 사실 회사 기술 블로그는 다양한 곳에서 작년부터 많이 공부하고 참고했던 지라, 언젠가 회사에 들어가면 막연하게 포스팅을 해보고 싶다..!..

🥴데일리

11월 즈음의 근황

아무도 궁금해하지 않지만 너무 글이 없으면 안 되니까 올리는 글.. 왜 개발 포스팅 올리지 않는가 요즘 워라밸을 충실히 지키며 취미 개발에 집중하는 중이라 그런지 개인 공부시간이 확 줄어들었다. 🥲 어떤 취미인지는 여기서 이야기하기는 조금 그런가? 그래도 연말까지 '2023 회고록' 이랑 '회사 테크 블로그에 게시글 올린 후기' 두 개는 꼭 올릴 예정이다. (회사 테크 블로그에 포스팅 올리는 것도 아직 미정이지만 ㅋㅋㅋ ) Github Actions 관련된 시시콜콜한 글도 적을까 했는데, 다수가 관심 있을 내용인지는 모르겠다. PR에서 helm chart의 values의 변경에 따른 템플릿 결과 yaml을 뽑고 ( "helm template . -f **-values.yaml" 같은 명령어 ) 리뷰할 때..

🏋️‍♀️ DevOps, SRE

Github Actions Kubernetes에서 self-hosted 설치&운영하기

Github Actions이 출시된 지 시간이 꽤 지나고 CI는 Github Actions으로 통합되는 분위기가 되어가고 있습니다. 이번에 Github Actions을 kubernetes에서 self-hosted로 설치하고 운영하면서 생긴 여러 이슈가 있어 공유해드리려고 합니다. 글이 좀 길 수 있습니다.ㅠ 2개로 쪼갤까 고민하다 합쳐서 올리게 되었네요. (발표자료를 먼저 만들고 블로그에 공유하는 것이라 발표 슬라이드처럼 생긴 이미지가 많을 수 있습니다!) Github Actions을 도입하고자 할 때 선택할 수 있는 여러 가지 방법이 존재하는데요, 먼저 대부분이 알고 계신 Github-hosted 방식입니다. 서버를 따로 프로비저닝 할 필요 없이 사용할 수 있어 운영 비용이 크게 발생하지 않는다는 점이..

🏋️‍♀️ DevOps, SRE

DevOps vs SRE , 차이점과 공통점에 대해

DevOps와 SRE, 어떤 차이가 있나요? 라는 질문은 항상 뜨겁습니다. DevOps 모임에서 이 질문이 나오면, 아마 모두가 각자 다른 대답을 할 것 같네요. 이 질문의 정답은 정답이 없다는 것입니다. 개인마다 이해와 생각이 다르니 비즈니스, 회사, 팀과 합의를 통해 개념을 정의하고 어떻게 받아들일지 정해야 하죠. 다만 이 질문에 대해서 각자 생각하는 정답지 하나 정도는 만들어 두는 게 좋죠. 세상을 바꾼 빅테크 SRE 챌린지라는 책에서 커뮤니티의 사람들이 생각하는 DevOps와 SRE에 대한 의견들을 받아 정리해 둔 부분 중 의미 있다고 생각된 몇 개의 의견들을 가져왔습니다. 여러 의견들 중 여러분에게 의미 있고 공감되는 글귀들을 중심으로 정리해보시길 바랍니다. 세상을 바꾼 빅테크 SRE 챌린지 |..

🏋️‍♀️ DevOps, SRE

짧은 생각 모음집 - crossplane, eBPF 편

crossplane, 이거 재밌는 아이디어 같다. crossplane은, 간단히 말하면 클라우드 리소스를 kuberenetes CRD로 정의해서 관리할 수 있도록 하는 프레임워크인데, Terraform을 yaml로 관리한다고 생각하면 쉽다. https://www.crossplane.io/ Crossplane - The cloud-native control plane framework Crossplane is a framework for building cloud native control planes without needing to write code. It has a highly extensible backend that enables you to build a control plane that ca..

🏋️‍♀️ DevOps, SRE

Kaniko : 도커 없이 kubernetes에서 이미지 빌드하기

CI 과정 중에서나 여러 다른 과정에서 kubernetes 클러스터의 파드 컨테이너 안에서 docker build로 이미지를 빌드하는 경우가 많습니다. 하지만 파드 안에서 이미지를 빌드할 때 docker를 사용하는 건 권장되는 방식이 아닌데요, 여러 가지 이유가 있습니다. 그리고 docker 대신 권장되는 방식이 있는데, 곧 소개할 Kaniko라는 친구입니다. 본격적으로 들어가기 전에, 기본적인 docker Host와 Client의 통신방식에 대해서 짚고 넘어갑시다. 컨테이너 이미지는 Dockerfile로 지정됩니다. 아시다시피 Dockerfile은 애플리케이션, 그리고 리소스를 기반으로 이미지를 빌드하는 방법을 설명한 설명서이죠. docker build 명령어로 설명서를 기반으로 컨테이너 이미지를 빌드..

newdeal
뉴딜의 서랍장