우분투 리눅스에 젠킨스 설치하기 – Installation Jenkins on Ubuntu

쉽게 해치우는 후루룩 개발 시리즈

우분투 리눅스에 Jenkins “젠킨스”를 설치합니다.

순서 요점정리

할 것은 이 정도입니다.

  • 우분투의 패키지 관리자인 apt로 젠킨스를 설치할 수 있게 해야합니다. apt가 아닌 다른 방법으로 설치하려면 성가시기 때문입니다.
  • 이걸하려면 apt 레파지토리에 젠킨스 배포체가 있는 곳의 주소를 넣어줘야 하고, 설치도 가능하게 인증키같은 것도 받아서 넣어주고 해야합니다.
  • 젠킨스는 Java 자바로 만들어져서 자바도 설치해야 합니다.
  • 젠킨스를 최초 구동을 한 후에 몇가지를 해줘야 하는데 그것까지 마저 해둬야 합니다.

젠킨스 배포 주소를 우분투 apt 레파지토에 등록하기

젠킨스는 두가지 릴리즈(배포) 버전을 제공합니다.

Long Term Support Relase 롱텀서포트 릴리즈

Weekley Release 위클리 릴리즈

롱텀서포트 릴리즈는 나중에 업데이트하지 않고도 오래동안 쓸 수 있는 매우 안정적인 버전이지만 업데이트가 잘 안됩니다.

위클리 릴리즈는 일주일에 한 번씩 업데이트되는 최신 버전이지만 버그도 있을 수 있고 조금 불안한 구석이 있습니다.

안전하게 롱텀서포트를 설치하는게 낫습니다.

젠킨스 설치하기

리눅스 쉘 명령어 세트입니다. 5줄로 되어 있는데 앞의 3줄은 한 세트입니다. 3개의 세트로 된 명령을 연달아 실행해 주면 설치가 됩니다.

자바 설치하기

OpenJdK라는 것을 설치하면 됩니다.

도커(docker)가 뭔가요?

쉽고 빨리 배우는 후루룩 개발 시리즈입니다.

Docker “도커”라는 것이 있습니다.

개발 세계에서 말하는 도커는 배가 정박하는 그 도커가 아닙니다.

도커를 흔히 컨텐이너라고 부릅니다. 화물 실어 나를때 배에 싣는 큰 쇠로된 상자인 컨테이너와 같은 것은 아니지만 개념은 비슷합니다.

1대의 서버에 전혀 다른 소프트웨어를 설치해서 사용하다보면 서로 궁합이 안 맞아서 한쪽이 설치가 안되거나 작동이 안되는 일이 발생합니다.

필요한 소프트웨어들을 버에 설치할 때 같이 필요한 소프트웨어들이 엄청 많이 필요할 수 있습니다.

몇 세트를 설치하다보면 이제 세트들끼리 서로 충돌을 하는 소프트웨어들이 생깁니다. 뭐 이런일들입니다.

세트A: ”b가 설치되어 있으면 나는 작동못해”

세트B: “b는 나한테 꼭 필요해”

이 외에도 여러가지 복잡한 일들이 생깁니다. 이 문제를 해결할 수는 있지만 소프트웨어 세트가 복잡하고 많고 오래될 수록 점점 지옥이 되갑니다.

그래서 하나의 서버에 전혀 다른 서버인 것처럼 환경자체를 가상으로 구별하고 마치 다른 소프트웨어가 설치되어 있지 않은 것처럼 깨끗하게 분리할 수 있는 방법이 개발되었습니다.

이걸 영어로 virtualziation “버추얼라이제이션”이라고 하고 우리말로는 “가상화” 라고 합니다.

도커는 가상화 소프트웨어입니다. 즉 서버의 환경을 분리해주는 것입니다.

물론 가상화는 이것보다는 설명할 것이 더 많습니다만 우선 여기까지만 이해하세요.

도커의 문제

  • 환경 분할해서 쓰는 OS는 리눅스만 가능해요.
  • 완전가상화가 아니기 때문에 OS자체를 전혀 다른 것을 설치할 수 없어요.
  • 완전가상화는 OS자체를 전혀 다른 것으로 바꿀 수 있어요. 하지만 도커는 완전가상화가 아니예요.

도커가 하는일

  • 리눅스 환경을 분리해서 전혀 다른 서버인 것처럼 나눠줘요.
  • 나눠진 환경에 소프트웨어를 설치할 수 있고, 코드를 짜서 넣을 수도 있어요.
  • 환경 자체를 통째로 받아서 저장해 둘 수 있어요. 이걸 도커 이미지로 만든다고 말해요.
  • 만들어진 이미지로 나중에 빵틀에서 빵찍어 내듯이 환경을 그대로 실행해서 작동하도록 만들 수 있어요.

도커를 쓰면 좋은 것

도커를 CI/CD에도 쓰면 좋습니다.

  • 도커로 서비스 소프트웨어를 만들어서 도커 이미지자체를 배포할 수 있습니다. 이게 편한 이유는 소프트웨어를 배포할 때 매번 서버의 환경이 소프트웨어가 구동하는데 필요한 환경과 일치하는지 확인해야 하고 안 앚으면 맞춰주고 해야 하는데 도커를 이용하면 필요가 없어집니다.
  • 매번 환경을 세로 만들기 때문에 환경을 구성하다가 환경구성에 필요한 소프트웨어가 갑자기 설치가 안되거나 오류가 발생했다거나 하면 그 사실을 알 수 있습니다. 소프트웨어가 동작하는 환경을 구성하는것 자체가 잘되는지 배포하기 전에 테스트를 할 수 있습니다.

별것 아닌것 같지 개발자를 편하게 해주는 것입니다.

CI/CD가 뭔가요?

문과능력자, 예능능력자 위한 개발 쉽게 이해하기 시리즈

개발자 용어로 CI/CD 라는 것이 있습니다.

“씨아이 씨디”라고 발음합니다. 콤팩트디스크 아닙니다.

CI/CD는 Continuous Integration / Cotinuous Deployment의 약어입니다.

CI = Continuous Integration 는 지속적 통합

CD = Continuous Deployment 는 지속적 배포

입니다.

용어가 어려워 보이지만 알고보면 별거 아닙니다.

소스코드를 소프트웨어가 실행되도록 구현체를 반드는 것을 빌드라고 합니다. 빌드를 소스코드를 고칠때마다 계속해서 실행해서 언제라도 소프트웨어를 배포할 수 있게 준비하는 것을 CI라고 부릅니다. 소스코드를 고쳐서 저장소에 업데이트할 때마다 자동으로 소프트웨어가 빌드됩니다.

그리고 자동으로 빌드된 소프트웨어가 자동 또는 반자동으로 서비스에 배포되는 것을 CD라고 합니다.

CI의 과정은 이렇습니다.

소스코드 고침 -> 빌드 됨 -> 자동으로 테스트 해줌 -> 빌드에서 오류가 발생하면 경고 메세지가 나타남 -> 다시 빨리 고침

CI를 하는 이유

  • 소스들 고치고 나서 빌드가 잘되는지 개발자가 확인하고 안되면 다시 수정하는 테스트 시간을 줄이기 위해서입니다.
  • 여러 사람이 소스코드를 동시에 편집하거나 같이 작업하기 때문에 각자 맡은 부분에서 자기가 고친 부분은 자기가 책임을 질 수 있게 하기 위한 것입니다.
  • 빈번하게 소스코드를 고치고 기능추가, 버그수정을 짧게 짧게 끊어서 하는 것이 더 효율적이고 관리도 편해서 그렇게 하기 위해서 입니다.

CD의 과정

가상 환경 준비 -> 빌드된 소프트웨어가 잘 작동하는지 테스트 -> 오류이면 경고 -> 패쓰 후에 자동으로 서비스에 적용 또는 제품소프트웨어 배포

CD를 하는 이유

서비스 업체(구글이나 네이버, 페이스북 같은데들)은 소프트웨어를 빌드한 후에 잘 작동하는지 실험하는 것도 큰 일이고 부담이 됩니다. 이것을 자동화해서 소프트웨어가 빌드될때마다 잘 작동하는지 지속적으로 테스트하고 테스트가 완료되면 자동으로 배포해서 최신으로 유지합니다.

다 개발자들 편하고 장애(에러)가 생기는 것을 줄이기 위한 것입니다.

DevOps

이런 일을 해주는 시스템을 만들고, 구축하고, 관리하는 사람을 요즘은 DevOps “데브옵스”라고 부릅니다.

Development Operations의 약어입니다. 즉 개발환경을 운영하는 사람을 말합니다.

그래서 DevOps는?

  • 소프트웨어 엔지니어입니다.
  • 개발도 조금 하지만 제품(판매하는 소프트웨어나 서비스소프트웨어)를 개발하지는 않습니다.
  • 개발환경을 구축하는데 필요한 개발만 합니다.
  • 하드웨어는 관리하지 않습니다.

참고자료

https://www.redhat.com/ko/topics/devops/what-is-ci-cd