클라우드 75일차

현재 구성은 위와같고

서버 안쪽에는 ansible과 gitlab이 설치되어 있는 상태이다.

 

그리고 vagrant를 이용해서 노드들을 배포했다.

실재 환경이라면 vagrant 를 쓰지 않고 새롭게 생성한 계정을 사용했을것이다.

 

ansible 자체에서 become:yes로 해주면 각 노드에 있는 root로 실행이 되게 된다.

 

gitlab을 동작시키기 위해서는 일종의 gitlab 자체에 접근하고 본인이 사용할 수 있는 도구(shell)와 사용자(gitlab-runner)가 필요했다.

 

실재 gitlab-runner은 /etc/passwd에 사용자로도 /etc/group 의 그룹으로도 등록이 되어 있다.

 

우리가 만약에 저장소에 코드를 올리게 되면 gitlab에서는 실행자체와 코드자체의 문제점을 모두 점검해본다. 만약 파일 자체에 문제가 있다면 그 다음 단계로 넘어갈 필요가 없기 때문에 Deploy 로 넘어갈 수 없게 된다.

 

우리가 해야하는 것은 server에서 yaml 파일을 만들고 이것을 ansible-playbook 이용하여 각 노드에 httpd를 설치해봐라였다.

---
- name: httpd installation
  hosts: all
  gather_facts: no

  tasks:
    - name: SELINUX disabled
      become: yes
      replace:
        path: /etc/selinux/config
        regexp: 'SELINUX=enforcing'
        replace: 'SELINUX=disabled'

    - name: httpd install
      become: yes
      yum:
        name: httpd
        state: present

    - name: start httpd
      become: yes
      service:
        name: httpd
        state: started
        enabled: true

그냥 이거 그대로 실행하면 알아서 설치된다.

 

---

해야하는 일

1. [ server ]에 gitlab을 설치한다.

gitlab과 상관없이, vagrant 계정에서 httpd.yaml 을 만들고

ansible-playbook httpd.yaml 을 이용하여 각 노드(node1~node3)에 httpd를 배포한다.

 

[ 확인 ]

윈도우 10에서 브라우저를 열고 http://211.183.3.201~211.183.3.203

 

2. 로컬 git 저장소에서 index.html 파일을 만들고 이를 git push 하여 gitlab 저장소로 올린다.

이를 감지한 gitlab runner는 .gitlab-ci.yaml 이 동작하여 index.html 파일을 각 노드의 /var/www/html로 이동시킨다.

 

3. 이후 개발자는 gitlab 신경 쓸 필요없이 index.html 파일의 내용만 수정하고 push 할 때마다 자동으로 각 노드에서 페이지가 변경되는 것을 확인할 수 있어야 한다.

 

개발자가 index.html을 gitlab에 올리면 이걸 감지한 gitlab-runner는 .gitlab-ci.yaml을 실행하고 여기에서는 ansible을 이용하여 index.html 파일을 각 노드들의 /var/www/html/index.html 로 전달하게 된다.

 

이게 저장소에 파일을 올릴때마다 끌어서 업로드 하면된다.

쓸모 없는 파일이 갈 수도 있기 때문에 깃랩 저장소를 따로따로 만들면 된다.

암튼 홈페이지를 올리기 올릴것과 docker에 올릴것들은 각각의 gitlab-runner을 따로따로 만들어서 사용하면 된다.

 

여기에서 중요한건 gitlab-runner은 gitlab-runner가 돌리고

ansible은 vagrant가 돌린다. 그래서 배포하기 위해 어떠한 방법으로 이걸 배포할 수 있을지 고민해 봐야한다.

 

---

gitlab은 자체적으로 CI를 제공한다.

CI 서버에서는 .gitlab-ci.yaml을 끌어와서 확인한다. 내부에 httpd.yaml 파일을 실행하라고 적혀 있으면

CI 서버에서는 .gitlab-ci와 httpd 파일을 가져온다. 그리고 내부 정보가 문제 있는지 테스트하고 빌드한다.

 

이후에는 실재 배포를 위한 단계가 필요하게 된다.

우리의 CI까지는 gitlab이 모두 지원해주는데

 

CD의 경우는

여기에서 말하는 코드는 CI를 거쳐 문제가 없으면 CD를 하게 된다. CD는 애플리케이션을 운영 환경으로 릴리즈 하는 작업을 자동화한다.

그래서 애플리케이션 배포단계를 Deploy라고 하는데 이거 직전에 저장소에서 최종 단계 이미지를 끌어다가 배포하게 된다. 이거 전 단계에 Dockerfile이 존재한다. 이 파일안에 문제를 검증하는건 CI이고 그 다음 단계인 저장소로 보내서 이미지를 만드는 것을 Delivery이다.

이 상태에서 이미지를 끌어다가 배포하면 Deployment이다.

 

그래서 위 이미지에서 절반은 코드영역이고 나머지는 운영영역이다.

왼쪽은 gitlab이 하고 오른쪽은 gitlab도 할 수 있지만...  jenkins(SVN, git)를 CD로 써서 배포할 수도 있다.

 

이전에도 jenkins의 git의 url에 github 주소를 썼는데 이제는 gitlab의 주소를 작성하면 되는 것이다. 그럼 jenkins가 이미지 만들고 배포까지 해주는 것이다.

 

그렇다면 고민해야하는 부분이 gitlab을 자체적으로 CI/CD를 모두 이용하고 싶다면 .gitlab-ci.yml을 이용하여 배포하면 된다.

 

CI는 gitlab, CD는 jenkins를 사용하겠다면 .gitlab-ci.yml이 아닌 Jenkins에서 Jenkinsfile을 만들어서 배포하면 된다.

 

그리고 Jenkins도 github와 연결할 수도 있고

github는 독자적으로 가지고 있는 webhook을 이용할 수도 있다.

gitlab-ce를 사용할 경우 내부 개발자들은 제약 조건없이 팀을 구성하여 협업하거나 사설 저장소를 생성하여 이용하거나 group 구성등을 자유롭게 사용할 수 있다.

 

CI쪽에서 담당하는 것은 build이다.(코드 문제 점검) 그 다음 Delivery에서 테스트를 한다.

특히나 테스트 자동화에서는 새로운 버전의 응용 프로그램 품질과 기능에 대해 점검, 파이프라인을 통한 보안, 성능, 컴플라이언스 검증을 한다. 이걸 모두 자동화 한다.

이게 끝나면 최종적으로 Deployment로 운영 환경 배포하게 된다. 즉 운영 환경 배포는 최종 배포 단계인 것이다.

 

CI/CD가 모두 되어 있는 환경에서 개발자는 코드만 올리면 자동으로 애플리케이션이 배포가 된다.

 

웹페이지를 보았을때 정상적인 페이지이면 그대로 배포

 

배포하기전에 조건으로 내가 직접 확인하겠다(manual)을 넣어주어서 내가 버튼을 눌렀을때 배포가 되도록 하겠다는 의미가 된다.

 

결국 위와같이 배포를 할 수 있다.

그럼 쉘대신에 docker을 쓸 수도 있다.

 

하지만 보통은 shell을 쓴다. 왜냐하면 우리는 도커 명령어를 모두 알고 파일도 만들 수 있으니 shell로 모든 것을 처리할 수 있는 것이다.

 

또 특정 브랜치에서만 실행 또는 특정 브랜치 제외도 가능하다.

 

오후에는 aws를 해보자