안녕하세요. 현재는 제품화개발팀에서 데이터 통계 사이트를 개발, 운영하는 12년 차 개발자 김수지입니다. 이전에는 Jira, Confluence, Gitlab, Jenkins 등 전반적인 개발 시스템 구축 및 운영을 진행하였습니다.각각의 시스템이 운영되면서 자동화 프로그램을 개발하게 되었습니다. 시스템 간의 연동을 하게 되면서 시스템 성능, 애플리케이션 배포, 인프라 상태 등을 한눈에 파악할 수 있도록 하는 우리의 개발 시스템에 맞는 사이트가 필요하다고 느껴졌습니다.DevOps는 개발(Development)과 운영(Operations)의 결합을 의미합니다. 코드의 품질, 제품의 생산성과 완성도를 위해서는 현재 우리의 상태를 파악하는 것이 가장 중요합니다. 데이터 시각화는 이러한 DevOps 프로세스의 효율성을 높이고 문제 해결을 더 신속하게 할 수 있게 합니다.DevOps 시각화에 필요한 요소는 크게 데이터 식별, 수집, 저장 및 관리, 시각화, 보완으로 나눌 수 있습니다. 각각의 요소는 DevOps 환경에서 데이터를 실시간으로 모니터링하고 분석하기 위해 필수적입니다. 아래에서 각 요소를 구체적으로 설명하겠습니다.DevOps 데이터 시각화에서 데이터 수집 단계는 전체 파이프라인의 핵심적인 기반을 형성하며, 개발 규칙, 방법론, 그리고 배포 흐름을 토대로 정량화할 수 있는 데이터를 API를 통해 수집하는 과정입니다. 이 과정에서는 로그 데이터, 메트릭, 배포 빈도와 같은 정량적 데이터를 다양한 시스템에서 가져와 분석과 시각화를 위한 원천 데이터로 사용합니다.각 단계에서 수집할 수 있는 다양한 데이터를 운영하는 규칙과 사이클을 토대로 기준을 세워 필요한 데이터를 정의합니다.1. 이슈 등록 : 기간별 등록된 이슈 수, 개발기간, 완료 여부, 등록부터 배포까지 소요 기간Jira에서 이슈 정보를 가져오거나, GitLab에서 프로젝트 정보를 가져오거나, Jenkins에서 빌드 상태에 대한 정보를 가져오려면 각 시스템에서 제공하는 REST API 호출을 통해 Raw 데이터를 가져옵니다. 이를 토대로 분석하려는 용도에 맞게 데이터를 가공합니다.REST API(Representational State Transfer Application Programming Interface)는 웹 기반의 서비스와 클라이언트 간의 통신을 위한 아키텍처 스타일입니다. REST는 리소스를 URI(Uniform Resource Identifier)를 통해 정의하고, 서버의 자원을 다양한 클라이언트에 구애받지 않고 사용할 수 있게 하는 설계 방식으로, HTTP 요청에 대한 응답으로 서버의 자원을 반환합니다.이때, 서버에서 보내는 응답이 특정 기기에 종속되지 않도록 모든 기기에 통용될 수 있는 데이터(JSON)를 반환하는데, 다양한 클라이언트의 요청에 일일이 View 페이지를 응답하는 것이 아니라, JSON 데이터를 응답하는 것입니다.우선, 데이터를 분석하고자 하는 개발, 빌드 시스템인 GitLab과 Jenkins REST API 기본적인 사용법에 설명하겠습니다.1. GitLa

안녕하세요. 여기어때컴퍼니 DevOps팀 루카스입니다. 저희 팀은 여기어때컴퍼니 Tech 조직내 개발자들의 업무 몰입을 위한 개발 환경과 체계를 만들어가는 조직으로 조직별로 상이한 개발 환경을 통합하고 운영하고 있습니다.Photo by Pankaj Patel on Unsplash이번에 다룰 주제는 팀에 합류하고 나서 첫 번째 작업이었던 GitLab 버전 업그레이드 과정입니다. GitLab은 소프트웨어 개발자에게 강력한 기능을 제공하는 형상 관리 플랫폼입니다. 하지만 최신 기능을 활용하고 보안 업데이트를 적용하기 위해서는 정기적으로 업그레이드를 해야 합니다. 우리 조직내 개발자들이 더욱 안전한 환경에서 신규 기능을 활용 할 수 있도록 저희팀은 GitLab을 업그레이드 하기로 결정하였습니다.1. 사전 준비1–1. Upgrade Path 확인GitLab의 현재 설치된 버전과 호환성을 확인합니다. 이런 경우에는 GitLab의 공식 문서에서 지원되는 업그레이드 경로를 확인하는 것이 좋습니다. https://gitlab-com.gitlab.io/support/toolbox/upgrade-path/ 이 URL에서 현재 사용 버전, OS, 업그레이드 대상 버전 등을 선택하면 어떤 버전의 순서로 업그레이드를 해야하는지 알려 줍니다. 버전 변경에 대한 큰 변동사항에 대해서도 미리 경고해 줍니다.여기어때에서는 GitLab 15.1.6을 사용하고 있었으며, 16.9.4 버전으로 업그레이드를 진행하였습니다.15.1.6에서 16.9.4로 Upgrade Path는 다음과 같습니다.15.1.6 → 15.4.6 → 15.11.13 → 16.1.6 → 16.3.7 → 16.7.7 → 16.9.1Upgrade Path의 경고 마지막 부분에 Expiring Access Token 부분이 있었습니다. Gitlab PAT 관련 문서를 통해 추가로 확인해 보았습니다. https://docs.gitlab.com/ee/user/profile/personal_access_tokens.htmlNever Expire로 발급된 Personal Access Token은 모두 GitLab 16.0으로 업그레이드한 날짜로부터 1년 후에 만료 되도록 강제로 변경 됩니다. CI/CD Pipeline 자동화를 위해서 사용되는 토큰인 경우, 만료시 장애를 일으킬 수 있는 원인이 되기 때문에 사전 작업을 진행합니다.1) 기존 버전의 Personal Access Token의 만료일이 Never인 Token을 리스트업합니다.$ curl -s --header "PRIVATE-TOKEN: ${your_access_token}" "https://${gitlab url}/api/v4/personal_access_tokens" | jq '.[] | {id, expires_at}'결과 샘플은 다음과 같습니다.{ "id": 154, "name": "GITLAB-PAT", "expires_at": "2025-06-25"}your_access_token 은 admin 권한을 갖는 계정의 Personal Access

안녕하세요, 이번 글은 개발을 진행하며 필수라고 생각하는 버전관리 시스템인 Git에 대해 다뤄보려 합니다. 우리는 Git에 대해 친숙합니다. 하지만 저를 포함해서 많은 분들이 단순한 사용 방법에 대해서만 알고 있을거라 생각이 되었고, Git이 무엇인지, 어떤 원리로 동작하는지를 알면 사용할 때 더 잘 쓸 수 있지 않을까 하여 이번 주제로 생각했습니다.버전 관리 시스템이란?버전 관리 시스템이란 VCS(Version Control System)이라 하여 파일의 변화를 시간에 따라 기록하여 과거 특정 시점의 버전으로 다시 불러올 수 있는 시스템 입니다. 가령 개발을 진행하다가 잘못된 코드를 작성하여 다시 되돌리고 싶거나 현재 개발중인 기능을 잠시 중단하고 hot fix로 버그 수정을 해야 할 때, 우리는 버전 관리시스템을 활용하여 효율적으로 개발을 진행할 수 있습니다. 이러한 버전 관리 시스템에는 로컬 버전 관리 시스템, 중앙 집중식 버전 관리 시스템, 분산 버전 관리 시스템으로 나누어 볼 수 있습니다.로컬 버전 관리 시스템Git과 같은 버전관리 시스템이 등장하기 이전을 상상해 보시죠. 우리는 버전관리를 위해 _최종, _최종의최종, _최종의최종의최종, _진짜최종 과 같이 파일을 만들어 두고 관리를 하거나, 디렉토리를 복사하여 이름을 해당 날짜를 추가하여 관리하는 방법을 사용했습니다. 이 방법은 간단하지만 실수를 하기도 쉽습니다. 만약 _최종을 만들고, _최종의최종을 만들었는데, _최종 파일을 _최종의최종에 덮어써버리는 실수를 한다면 버전 관리가 실패할 수 있습니다.이러한 문제를 해결하기 위하여 간단한 데이터베이스에 파일의 변경 사항을 기록하는 RCS와 같은 로컬 버전 시스템을 개발하였습니다.local version control system중앙 집중식 버전 관리 시스템중앙 집중식 버전관리 시스템은 여러 개발자들과 함께 개발하기 위하여 만들어졌습니다. 파일을 저장하는 하나의 중앙 서버가 있고, 여기에서 각 개발자들(Client)은 파일을 가져와서 개발을 하는 방법입니다. 예를 들어 CVS, Subversion, Perforce 등이 있습니다. 장점으로는 같이 개발하는 사람이 어떤 작업을 하고 있는지 알 수 있습니다. 중앙 서버만 보면 어떠한 작업이 일어났는지 쉽게 알수 있죠. 이는 각 개발자들의 컴퓨터에 로컬 데이터베이스를 가지며 개발하는 것보다 관리면에서도 쉽습니다.하지만 단점도 있습니다. 중앙서버가 다운되면 모든것이 다 위험해질 수 있따는 점이죠. 서버가 다운되면 다시 복구될 때 까지 버전관리는 힘들어집니다.Centralized Version Control System분산 버전 관리 시스템위의 버전 관리 시스템들이 발전해오면서 현재의 분산 버전 관리 시스템이 탄생하게 됩니다. 우리가 잘 알고 있는 Git을 포함하여 Mercurial, Bazaar, Darcs 등이 있습니다. 클라이언트가 저장소를 통째로 복사하는 방식으로 각 클라이언트가 하나의 중앙 서버 역할을 하는 셈이 됩니다. 따라서 서버에 문제가 생겨도 다른 클라이언트에 복제된 저장소를 다시 서버로 복사하면 서버가 복구되게 되는 셈이죠.Distributed Version Control SystemGit에 대하여그럼 이제 Git에 대해 조금 더 알아보도록 하겠습니다. Git의 탄생 배경에 대해 조금 알아보면 리눅스 개발 커뮤니티에서 만들어 졌음을 알 수 있습니다. 리눅스 커널은 패치 파일과 단순 압축 파일로 버전을 관리하였고 BitKeeper라는 사용 분산 버전 관리 시스템을 사용하기 시작했습니다. 그러다 Bitkeeper가 무료사용이 힘들어지면서 리눅스 개발 커뮤니티에서 자체 도구를 만들게 되는데, 이것이 Git 입니다.Github? Gitlab?우리는 Git을 사용하다 보면 Github과 Gitlab이라는 단어를 많이 보게 됩니다. 이 두 서비스는 모두 Git을 기반으로 하고 있다는 점에서는 공통점이 있는데요, 차이점은 어떤게 있을까요?GithubGithub를 사용하면 CI/CD(지속적 통합 / 지속적 전달) 도구를 직접 통합해야 합니다. Jenkins, CircleCI, TravisCI 같은 3rd party 프로그램을 사용해야 합니다. 또한 Github에서는 Branch 전략이라는 것이 있을 정도로 Branch의 관리를 강조합니다. 새로운 Branch를 master Branch와 병합하는 것이 용이합니다. 이와 같은 이점으로 인해 신속한 배포, 트러블 슈팅이 용이한 장점이 있습니다.또한 Github는 외부 프로그램 및 서비스와 통합하는 쉬운 방법을 제공합니다. 다양한 외부 서비스와 프로그램, Github와 통합을 위한 소프트웨어를 이용할 수 있습니다.그리고 Github에서는 협업을 할 때 PR(Pull Request)를 요청하여 main Branch에 병합을 요청합니다. 작업을 하기 위한 첫번째 액션이 pull 이기 때문이라고 하네요.GitlabGitlab은 CI/CD와 DevOps workflow를 내장했습니다.  또한 Gitlab의 workflow는 master Branch와 별도의 안정적인 Branch를 생성합니다. Production과 Staging의 분기가 최소한으로 있고 이러한 다중 분기 접근 방식은 여러 단계의 테스트 프로세스가 필요, 병합 요청시 코드 검토가 까다로워 집니다. 또한 Gitlab은 완전한 소프트웨어 개발 솔루션을 제공하며, All-in-One의 DevOps 플랫폼이라고 강조합니다. Gitlab은 jira, Teams, slack 과 같은 다양한 어플리케이션 및 플랫폼과 통합을 제공합니다.Gitlab에서는 협업 시 MR(Merge Request)를 요청하여 main branch에 병합을 요청합니다. 이는 Github와는 조금 다른 입장에서 보는데 할당된 사람에게 요구되는 최종 action이 merge이기 때문이라고 합니다.두 서비스는 차이점만 있는게 아니라 공통점도 여럿 있습니다. 리눅스 서버에서 실행된다는점, 이슈 트래커 제공, 넓은 범위의 도구를 제공한다는 점등은 공통점입니다.Deep dive into GitGit에서 관리하는 데이터는 파일의 스냅샷 입니다. 파일이 달라지지 않으면

AKS 환경에서 DevOps 사례를 만들어 보자AKS 를 도입하고 나서 보니 개발자들의 서비스 배포에 드는 수고가 절반은 줄어든 것으로 보인다.기존 Azure VM 기반에서는 오토스케일링을 위해 VM 이미지 기반 배포가 요구되기 때문에 이미지 업데이트와 배포 과정에서 많은 시간이 소요되었다.개발자 입장에서는 중요하지 않은 업무로 효율성이 떨어졌다.AKS 도입 후 CI/CD 파이프라인을 구축하여 개발자의 수고를 줄일 수 있었다.최근 별도의 개발 프로젝트 진행을 위해 인프라 제공이 필요했는데, AKS가 있어 어려움 없이 2일 만에 제공할 수 있었다.CI/CD 관점으로 GitLab에 소스 저장소 생성부터 ACR로의 이미지 업로드, ArgoCD를 통한 자동 배포까지의 과정을 정리하였다CI환경은 Gitlab CI로 구성을 할 수 있다repo는 source-repo와 manifest-repo로 분리하여 구성한다. 2개의 repo를 그룹으로 관리할 수 있도록 gitlab의 subgroup 기능을 이용한다.동작을 하기 위해 간단한 spring boot 샘플 소스를 작성한다. 간단한 웹 페이지가 보이도록 src/main/resources/static/index.html에 작성한다.1) gitlab-runner에 대한 이해 부터처음에는 gitlab에 있는 runner가 CI/CD 처리를 해 주는 줄 알았다.shared runner(공유 러너) 환경이라면 틀린 말도 아니지만 현재 우리 회사는 아래 그림처럼 shared runner를 구축하지 않았다.그래서 프로젝트 담당자가 gitlab-runner를 구축해야 한다.우선 gitlab에서 정의하는 runner와 실제 CI/CD 수행을 하는 gitlab-runner를 구분해서 이해하고 있어야 한다.• None 정의 : gitlab-runner는 gitlab의 CI/CD 파이프라인을 구동하기 위한 agent로, 코드 변경에 따른 자동화된 테스트, 빌드, 배포 등을 수행하는 도구• None 필요성 : gitlab에 호스팅된 프로젝트의 continuous integration/delivery를 위해 필요, 코드 변경 시 자동으로 테스트, 빌드, 배포 등을 수행할 수 있음repo 단위로 runner를 설정할 수도 있지만, group내에 다수 repo가 존재할 상황이라 group runner를 등록하기로 했다.group의 Build 메뉴를 펼쳐서 'Runners' 를 클릭하면 'New group runner'를 생성할 수 있는 기능이 제공된다.아래와 같이 tag를 입력하고 Create runner를 클릭하면 바로 생성이 된다.Runner created. 라는 알림이 뜨고, 하단의 Go to runners page 를 클릭하면 등록된 runner를 볼 수 있다.좀 전까지도 없었던 gorup runner가 등록된 걸 볼 수 있다. 현재 상태는 Online에 Never connected 이다. 아직 연결된 것 없다.아직 연결 전이므로 연결이 필요하다. 실제 역할을 수행할 컴퓨팅 자원이 필요하다.우리 프로젝트는 aks를 사용하므