Architecture

[papavhub]

[papavhub]

[papavhub]

• GitHub의 DevSecOps

GitHub의 DevSecOps : 깃허브는 GitHub Advanced Security 를 사용해 DevSecOps를 자동으로 실행할 수 있음.

• 코드검사
• 오래되거나 취약한 패키지, 응용프로그램 확인
• 취약성 관리

<깃허브의 취약점을 식별하는 다이어그램>

1. GitHub Security가 해당 리포지토리 관리자에게 메일 경고를 보냄.
2. GitHub Dependabot은 취약한 패키지 및 응용프로그램을 자동으로 탐색하는 봇. 취약점 발견시 다음 작업을 자동으로 완료함.
   • 해당 리포지토리에서 새로운 브랜치 생성
   • 취약성을 보완하기 위해 라이브러리 검사, 자동 업데이트 -> 새 브랜치에서 작업
   • 업데이트 한 브랜치를 Pull Request 함.
3. Pull Request 승인시 merge 후, 기존 브랜치와 병합됨.
4. 머지 후 CI/CD 작업 실행
   • 마스터 브랜치에서 앱을 추출하여 배포
   • CI/CD : 개발>빌드>테스트 자동화(CI) 및 배포 자동화(CD)
5. 테스트 또는 스테이징 환경에 새 앱 버전을 배포함.
   • Azure 같은 배포 템플릿을 이용하여 배포.

• URL https://docs.microsoft.com/ko-kr/azure/architecture/solution-ideas/articles/devsecops-in-github

[papavhub]

• AWS 서비스를 사용한 Git Webhook (이것도 아닌거 같음 한번 읽어봐주세요)

• Git 리포지토리를 AWS 클라우드에 연결하기 위한 HTTPS 엔드포인트 및 코드

• 설명 이 Quick Start는 Git와 AWS 서비스를 연결하는 Webhook를 구성할 때 사용할 수 있는 HTTPS 엔드포인트를 배포합니다. Webhook를 구성하면 Git 사용자가 커밋을 푸시할 때마다 리포지토리가 자동으로 검색되고 압축된 후 Amazon Simple Storage System(Amazon S3) 버킷에 업로드됩니다. 리포지토리가 업로드된 후에는 AWS CodePipeline, AWS CodeBuild 및 AWS CodeDeploy 등 S3 버킷을 소스로 사용할 AWS 서비스를 구성할 수 있습니다.

• URL https://aws.amazon.com/ko/quickstart/architecture/git-to-s3-using-webhooks/

---

— AWS 서비스를 사용한 Git Webhook

• 웹후크를 구성하여 Git 및 AWS 서비스를 연결하는 데 사용할 수 있는 HTTPS 엔드포인트를 배포
• Webhook을 사용하면 Git 사용자가 커밋을 푸시할 때마다 리포지토리가 자동으로 검색되고 압축되어 Amazon Simple Storage Service(Amazon S3) 버킷에 업로드
• S3 버킷을 소스로 사용하도록 AWS CodePipeline, AWS CodeBuild 및 AWS CodeDeploy와 같은 AWS 서비스를 구성할 수 있
• Quick Start를 배포한 후 제공 하는 엔드포인트 정보 를 사용 하여 Git 서비스에서 웹훅을 구성

— AWS code deploy

• 다양한 컴퓨팅 서비스에 대한 소프트웨어 배포를 자동화하는 완전관리형 배포 서비스

— AWS CodeBuild

• 소스 코드를 컴파일하는 단계부터 테스트 실행 후 소프트웨어 패키지를 개발하여 배포하는 단계까지 마칠 수 있는 완전관리형의 지속적 통합 서비스

=> 필요없음

[papavhub]

• Using Custom Source Actions in AWS CodePipeline for Increased Visibility for Third-Party Source Control

• URL https://aws.amazon.com/ko/blogs/devops/using-custom-source-actions-in-aws-codepipeline-for-increased-visibility-for-third-party-source-control/

간단하게 말하면 저거는 깃허브가 아니라 깃 레포지토리에 있는거 배포하는 거 같음

AWS S3 : 깃허브 레포지토리라고 생각하면 편함

• 정적인 페이지 호스트 해줌
• Bucket 생성 (https://sestory.tistory.com/151?category=642880)
• Git push (https://sestory.tistory.com/153?category=642880) : 이거는 저희한테 맞는것 같습니다. 깃허브 호스트대신에 이거 쓰면 되는 것 같음

Pipeline : 배포할 때 쓰임 https://docs.aws.amazon.com/ko_kr/codepipeline/latest/userguide/tutorials-s3deploy.html (공식문서 - 안읽어도 됨)

• 빌드/배포 자동화 시스템 구축 https://urbanbase.github.io/dev/2019/07/02/AWS-CodePipeline.html : 이슈 사진은 깃허브 소스를 배포하는 과정인 듯 합니다. 위 링크의 AWS CodePipeline 단계별 설명을 보면 이해 갈 듯 해요..

=> 결론 : AWS S3를 이용하는 방향으로가는건 어떻습니까?

[papavhub]

• 이거 뭔지 한번 읽어봐주세요 https://programmaticponderings.com/tag/continuous-delivery/

[papavhub]

• Github 구조

1. Commit

   • ssh > GitLab Shell > Redis > Sidekiq > Gitlab rails > postgreSQL
2. Clone

   • postgreSQL > Gitlab rails > unicorn > GitLab Shell
3. Website

   • GitLab Pages > gitlab workhorse > unicorn > gitlab rails > postgreSQL
4. Website 접속

   • nginx > gitlab workhorse > GitLab Pages

• URL https://stackoverflow.com/questions/4892602/how-does-the-github-website-work-architecture

[papavhub]

• GitLab 구조

• URL https://docs.gitlab.com/ee/development/architecture.html

[pjy7814]

[ghost]

[Jimin731]

[pjy7814]

최종

[pjy7814]

Github, GitLab 구조

- Nginix : 동시 접속 처리에 특화된 웹서버 프로그램, - Gitlab Workhorse : GitLab용 스마트 리버스 프록시/ 파일 다운로드, 업로드, 깃 푸시 풀 등 대규모 HTTP 요청 처리 - 리버스 프록시 : 캐싱, 보안, Load Balancing - Unicorn : 빠른 클라이언트 및 Unix를 위한 랙 HTTP서버 - Ngnix 서버랑 연동이 잘 됨 - rails의 기본 서버가 webrick인데 배포용으로 좋지 않아서 passenger, mongrel, unicorn, thin, puma 사용하는데 그 중 unicorn 사용한듯 합니다 - PostgreSQL : 오픈소스 DB - GitLab Rails : Ruby on Rails - 오픈 소스 웹 프레임워크 - MVC 패턴 - Redis : 캐시 서버 (https://brunch.co.kr/@jehovah/20) - 키 -값 기반의 인메모리 데이터 저장소 - sidekiq이랑 같이 쓰임 - 디스크에 지속되는 메모리 내 데이터베이스 - Sidekiq : 비동기 작업 처리 - Ruby on Rails 안에 들어있는 듯 - Redis에 의존적 사용하려면 redis 서버 설치 필수 - Rails - redid - sidekiq (https://kbs4674.tistory.com/85) - Ruby 용 백그라운드 처리, redis를 작업 관리 저장소로 사용 - GitLab Shell : ssh를 통해 리포지토리 제공 —————— - Puma : Rails 5.0 기본 서버 - Gitaly : NFS(Network File System) 없이도 Git 레파지토리에 대한 RPC 기반의 빠른 읽기/쓰기를 가능하게 하는 오픈소스 서비스 - gitLab 고가용성을 보장 - Git 레파지토리의 오류를 줄이고 복제된 저장소를 얻을 수 있음

[pjy7814]

• Gitlab shell : 애드온 애플리케이션 (https://gitlab.com/gitlab-org/gitlab-shell/-/blob/main/README.md)

  • SSH 기반 git세션 을 처리 하고 인증된 키 목록을 수정 하기 위해 GitLab에서 설계된 프로그램
  • SSH를 통해 GitLab 서버에 액세스하면 GitLab Shell은 다음을 수행
    1. 미리 정의된 git 명령(git push, git pull)으로 제한합니다.
    2. GitLab Rails API를 호출하여 권한이 있는지 확인하고 저장소가 어떤 Gitaly 서버에 있는지 확인합니다.
    3. SSH 클라이언트와 Gitaly 서버 간에 데이터 복사

• sidekiq 쓰는 이유 : 이메일 보내기, SMS 보내기, PDF 생성, 엑셀 파일 생성 등과 같은 작업은 서버에서 시간이 많이 소요될 수 있습니다. 서버가 이러한 작업을 시도하는 동안 서버는 다른 요청을 처리할 수 없습니다. 이것은 서버의 처리량을 감소시킵니다. 이는 들어오는 요청을 처리하기 위해 더 많은 서버가 필요하다는 것을 의미합니다. 더 나은 전략은 요청을 받아 백그라운드에서 처리하도록 저장하는 것입니다. 이런 식으로 누군가가 "비밀번호 재설정"을 요청할 때 서버는 즉시 응답을 보낼 수 있습니다. 사용자는 "비밀번호 이메일이 전송 중입니다"라는 알림을 받습니다. 백그라운드에서 서버는 모든 백그라운드 작업을 하나씩 처리할 수 있습니다. (https://www.bigbinary.com/learn-rubyonrails-book/background-job-processing-using-sidekiq)

• redis랑 sidekiq 연결 이유 : 사이드킥에 잡을 등록하기 위해서는 태스크를 저장할 레디스 서버가 필요

[Jimin731]

Github, GitLab MSA 구조 (+Container) : 컨테이너 기반 마이크로 서비스 아키텍처

• 애플리케이션의 기능들을 분리하여 개발, 관리 진행 및 배포
• 장점: 서비스 단위로 개발 진행 가능 -> 효율적
• 단점: 서비스 분산으로 인해 트랜잭션 보장, 테스트, 배포를 따로 해야함으로 관리 복잡
• 컨테이너들을 쉽게 관리, 배포할 수 있는 Docker 주로 사용
• 예시
  • 넷플릭스 : 다수의 가입자들에게 높은 재생 품질을 다운타임 없이 서비스 하는 것을 목표로 MSA 적용
  • 아마존 : 줄 서지 않고 제품을 구매할 수 있는 식료품점 등을 통해 디지털 전환 가속화, 개별 서비스 혁신, 새로운 기술 기반의 서비스 개발 및 통합을 위해 마이크로 서비스 아키텍처를 사용
  • 쿠팡: 부분 장애가 서비스 전체 장애로 이루어지고, 조직이 성장할수록 배포 대기시간이 비약적으로 증가해 MSA로 전환
  • Bingle, SK Planet, PAYCO 등 . http://blog.creation.net/microservices-architecture-korean-cases (국내 도입 사례)

GitLab Rails (Puma)

• GitLab Rails : Ruby on Rails 기반
  • Ruby 기반 웹어플리케이션 프레임워크
  • 장점
    • 생산성 향상
    • 코드 일관성
    • 코드 재사용성 향상
  • MVC 패턴을 이용 -> 레일즈 어플리케이션 동작을 위해 HTTP서버, 데이터베이스 필요 https://docs.gitlab.com/ee/administration/operations/rails_console.html (rails에 대한 깃랩 공식 문서)

Puma

• Ruby 애플리케이션을 위한 다중스레드 및 동시성 높은 HTTP 1.1 서버
• GitLab 13.0 부터 Puma가 기본 웹 서버가 되고, Unicorn이 비활성화 됨 https://docs.gitlab.com/ee/administration/operations/puma.html (gitlab의 Puma 공식 문서)

PostgreSQL (+이유)

• PostgreSQL : SQL 언어를 적용한 고급 오픈소스 객체 관계형 시스템(DBMS)
• 사용하는 이유
  • 주로 대기업에서 사용
  • 크고 정교한 데이터를 안전하게 저장 가능
  • 데이터 유효성, 데이터 무결성 보장
  • 동시성처리 & 빠른 결과
  • Python, JavaScript, C, C++, Tcl, Perl 다양한 언어와 함께 작동
• gitlab의 경우에는 rails에 연결해서 사용 https://fulcrum.rocks/blog/why-use-postgresql-database/ (PostgreSQL의 설치 방법과 다른 데이터베이스와의 비교) https://docs.gitlab.com/omnibus/settings/database.html (gitlab의 데이터베이스 세팅)

[papavhub]

[papavhub]

— Nginx (vs apache)

• Routes requests to appropriate components, terminates SSL
• 엡 서버 소프트웨어
• 이벤트 기반 & 비동기 방식
• 트래픽 많은 웹사이트의 확장성
• 다수의 연결을 효과적으로 처리 가능
• Non-blocking
• Single-threaded

— Gitlab workhorse https://gitlab.com/gitlab-org/gitlab-workhorse

• Smart reverse proxy, handles large HTTP requests
• Handle slow HTTP requests for GitLAB

[papavhub]

https://blog.shikisoft.com/sharing-aws-codecommit-repo-with-devs/

[pjy7814]

swift에서 c++ 사용 https://ichi.pro/ko/swifteseo-c-kodeuleul-sayonghaneun-bangbeob-198832457836937

[papavhub]