🍕 배포를 위한 AWS Cloud 환경 구성 리뷰
직전 포스팅에서 로컬에서만 사용했던 Jenkins 서버, Docker 서버, Tomcat 서버, Ansible 서버, Sonarqube 서버를 클라우드에 구축해 사용해보자.
Jenkins 서버 설치 -> Tomcat 서버 설치 -> Docker 엔진 설치
Git에서 가져왔던 소스코드를 Jenkins에서 빌드를 하고 Tomcat 서버 배포 or Docker 컨테이너 형태로 생성하는 과정을 테스트 해보자.
다음으로 Ansible 서버와 Sonarqube의 연동을 구축해보자.
Ansible 서버에서는 앞선 포스팅에서 봤듯이 Jenkins에서 빌드 되어진 결과 파일을 Ansible 서버가 가지고 있다가 Docker or Tomcat or Sonarqua에 정보를 전달했었다.
앞에와 같은 구조로 동일하게 서버 시스템을 구축을 해볼 것이다.
위 그림을 보면 Jenkins 서버와 Tomcat 서버가 8080을 사용하고 있다.
이전 로컬 환경에서 테스트할 때는 하나의 PC에 여러가지 서비스가 구동되어야 되기 때문에 같은 포트를 사용할 수가 없었다.
하지만 클라우드 서버로 구동하면 서로 다른 ip 이기에 포트 번호가 같더라도 아무 상관이 없다.
🍔 AWS EC2 인스턴스 생성 및 접속
EC2(클라우드 가상 서버)를 생성하기 위해 인스턴스 시작을 눌러준다.
이때 상단 오른쪽에 있는 리전은 꼭 서울로 선택해야 한다.
이름 및 태그라고 되어있는 정보에 cicd-project-ec2라고 적어주었다.
그 밑에 Application with OS Image 아마존 서비스에서는 OS 이미지를 AMI, 아마존 머신 이미지라고 해서 AMI 라고 부르고 있다.
EC2 인스턴스를 나중에 이미지화해서 다른 쪽에 있는 서비스들에서 복사해서 사용할 수 있게 만들 것이다.
아마존 리눅스를 선택해주었고, 본 계정은 프리티어로 사용하고 있기 때문에 AMI 타입은 프리티어 사용 가능한 타입을 선택해주었다.
다음으로 인스턴스 유형이다. 이는 하드웨어의 스펙, 하드웨어의 성능이라고 할 수 있다.
프리티어 사용 가능이라고 적인 t2.micro를 선택해주었다.
키페어(로그인)은 인스턴스에 접속하기 위한 암호 정보가 들어가 있는 파일이다.
키페어가 존재하지 않는다면 오른쪽에 보이는 새 키페어 생성 버튼을 클릭한다.
여러분들이 사용할 키페어의 이름을 입력해준다.
나는 cicd-project-key라고 적어주었다.
다른 옵션은 그대로 둔 상태에서 생성을 눌러준다.
자동적으로 키페어가 PC에 다운로드가 됐다.
그 밑에 네트워크 설정이 있는데 기본적으로 변경하지는 않겠지만 방어벽이라고 되어 있는 부분에 보안그룹 생성과 기존의 보안그룹 선택이라는 것이 있다.
보안 그룹이라는 것은 만든 이 인스턴스에 외부에 있는 서비스가 접속을 할 수 있는 권한과 내부에 있는 서비스가 외부로 나갈 수 있는 권한과 그 두 가지를 설정하는 거라 보면 된다.
보안 그룹이 생성이 되면서 SSH에 접속할 수 있는 기본적인 정보는 포함될 수 있도록 선택하였다.
다음 스토리지 구성엔 8GB가 기본으로 선택되어 있는데 그대로 사용하기로 한다.
기본적으로 사용할 인스턴스가 5개 정도 필요하다.
5가지를 개별적으로 만들지 않고, 하나의 인스턴스에 필요로 하는 정보를 다 설치한 다음에 그 인스턴스를 이미지화해서 만들어 놓을 것이다. 그렇게 만들어진 이미지를 가지고 복사해서 사용하는 방법을 쓰도록 하겠다.
따라서 인스턴스 개수는 1개 선택하고 시작을 눌러주었다.
인스턴스 생성이 되었고
인스턴스 상태가 실행중으로 바뀌었다.
퍼블릭 IP주소는 인스턴스에 부여되어 있는 고유한 IP 주소이다.
퍼블릭 IP주소로 로컬 PC에서 SSH 클라이언트 툴로 접속을 시도해 볼 것이다.
또한 퍼블릿 IP주소는 인스턴스를 중지하고 다시 시작하면 변경된다.
만약 중지했다가 다시 기동을 해도 계속 유지가 되는 고정 IP address를 쓰고 싶다면 탄력적 IP(Elastic IP)를 생성하여 인스턴스하고 매칭해서 사용할 수 있다.
Tuminus를 사용해서 접속할 수 있는 호스트를 등록해보자
상단에 NEW HOST를 눌러 labe에 AWS-EC2-1 이라고 등록을 해주고, IP 주소는 위에서 확인한 퍼블릭 IP주소를 적어준다.
Credentials from의 아마존 리눅스 같은 경우엔 username이 ec2-user로 고정되어 있기 때문에 ec2-user라고 적어주었다.
그 밑에 다운 받았던 key 값을 사용하기 위해 선행되어야 할 작업이 있다.
왼쪽 상단에 톱니바퀴를 누르면 Settings이 나온다.
왼쪽에 Keychain 이라는 탭을 확인할 수 있는데, 누르면 SSH Key라는 메뉴가 나온다.
Add를 클릭해주고
Label은 AWS EC2-key, 위에서 다운받은 Key 파일을 Drag and drop 하면 자동으로 Private key에 Key 값을 가져온다.
AWS EC2-key 이름으로 만든 Key를 적용시켜 주고 Connect를 눌러 접속을 시도한다.
처음 접속을 시도하면 프롬프트 창에서 SSH 처음 접속했을 때와 마찬가지로 키를 하나 등록할건지 물어본다.
여기서 add and continue 라는 버튼을 클릭해 준다.
정상적으로 접속이 되었다.
접속이 특별한 문제 없이 가능한 이유 중 하나가 보안 탭에 보면
인바운드 규칙, 아웃바운드 규칙 두 가지를 설정할 수 있다.
인바운드 규칙은 외부에서 생성한 EC2에 접속할 수 있는 포트를 제어하는 기능이다.
아웃바운드 규칙은 인스턴스에서 외부로 나갈 때 사용되는 규칙이라고 보면 된다.
인바운드 규칙을 변경하려면 상단에 보안그룹을 선택한다.
들어가면 인바운드 규칙 편집을 클릭해준다.
현재 등록되어 있는 인바운드 규칙은 22번 포트에 대해서 어떤 IP 어드레스를 이용한다 하더라도 접속 가능하도록 되어 있는 상태(모든 사용자(=0.0.0.0))이다.
여기에 앞으로 Tomcat 서버, Jenkins 서버 등 다른 서비스를 이용할 때 필요한 포트 번호를 등록해 규칙을 추가할 수 있다.
java -version
yum list java*jdk devel
sudo curl -L https://corretto.aws/downloads/latest/amazon-corretto-11-x64-linux-jdk.rpm -o aws_corretto_jdk11.rpm
sudo yum localinstall aws_corretto_jdk11.rpm.rpm
다시 Terminus로 돌아와 Java 버전을 확인해 봤더니 현재 설치되어 있는 Java가 없다.
yum list java*jdk devel로 사용 가능한 jdk 버전을 확인해보니 1.8까지만 지원이 되고 있다.
버전 11을 써야 함으로 아마존에서 제공하고 잇는 오픈 jdk인 amazon-corretto 제품을 다운받았다.
이어서 jdk11.rpm을 다운받아준다.
sudo /usr/sbin/alternatives --config java
java -version
sudo /usr/sbin/alternatives --config java로 기존에 설치되어 있는 JDK 가 있다면 선택하여 사용하려 했으나 기존에 설치된 JDK가 없어 1번을 사용하도록 해주었다.
그리고 자바 버전을 확인해보니 11로 잘 설정된 것을 확인할 수 있다.
인스턴스를 잠시 중지하고
작업 -> 이미지 및 템플릿 -> 이미지 생성 으로 이미지를 생성해준다.
이미지 생성한다는 것은 현재까지 작업한 인스턴스의 상태값을 하나의 단일 파일로 만든다는 이야기이다.
이미지 이름을 cicd-proejct-image라고 설정해주고, 이미지 생성 버튼을 클릭해주었다.
왼쪽 메뉴에 AMI를 클릭하면 생성된 이미지를 확인할 수 있다.
🍟 이미지를 이용해 AWS EC2 생성
인스턴스 시작을 눌러 실행해주고, jenkins 서버로 사용하기 위해 이름은 cicd-project-jenkins로 변경해주었다.
보안 탭을 눌러 내리면 보안 그룹을 볼 수 있다.
앞서 말했듯 보안그룹은 인스턴스가 사용할 수 있는 포트를 열고 닫는 걸 관리할 수 있다.
즉, 인바운드 규칙에 포트를 열어놓아야 외부에 있는 서비스에서 접속이 가능한 상태가 된다.
인바운드 규칙에 22번만 되어 있기 때문에 외부에서 SSH 접속이 가능한 상태이다.
여기에 태그 이름을 붙이고 싶다면 보안그룹 링크를 클릭하고
launch-wizard-2 이라는 태그를 변경할 수 있다.
태그관리를 클릭한다.
비어있는 태그에다가 키는 Name, 값은 cicd-project-sg라고 적고 변경사항을 저장한다.
현재 인스턴스 한 개만 구동 중인데, 만들어 놓은 이미지를 가지고 새롭게 사용할 인스턴스를 추가해주자.
인스턴스 시작을 누르고, 이름은 cicd-project-ec2라고 적어준다.
이미지는 내 AMI를 선택하여 내 소유 , cicd-project-image를 선택해준다.
인스턴스 유형은 프리티어 사용 가능한 t2.micro를 선택해주었다.
네트워크 설정에 보안 그룹을 생성하지 말고 기존 보안 그룹 선택을 누르고, 이미지에서 할당되어진 보안 그룹 launch-wizard-1를 선택해주었다.
Tomcat, Docker, SonarQube, Ansible에서 필요하기 때문에 인스턴스 개수는 4개로 설정해주었다.
4개의 인스턴스가 추가로 실행되고, 이름을 각각 Tomcat, Docker, SonarQube, Ansible로 설정해주었다.
다섯 개의 인스턴스는 같은 네트워크에 묶여 있다.
가상 네트워크인 VPC(Virtual Private Cloud)는 모두 동일한 것을 사용 한다.
Terminus로 가서 인스턴스에 맞게 ssh 클라이언트 접속을 하기 위해
기존에 만든 만든 항목을 복사해주고
각 항목에 IP주소와 이름을 올바르게 설정해주면 된다.
5개의 ssh 클라이언트를 모두 세팅해주었다.
ping [통신하고자 하는 인스턴스의 사설 ip주소]
Jenkins에서 각각의 인스턴스로 사설 ip 주소로 ping을 보내 접속 테스트를 해보자.
그러나 Jenkins 서버에서 현재로써 Docker 서버로 Private IP 어드레스는 접속이 되지 않고 있다.
이 이유는 보안그룹에 현재 사용하고 있는 각각의 서비스들끼리 통신을 할 수 있도록 설정이 되어 있지 않기 때문이다.
보안그룹의 인바인드 규칙으로 가서 편집을 눌러준 다음에
유형은 모든 ICMP-IPv4으로 설정하고, 이전처럼 모든 것을 허용하는 0.0.0.0으로 설정하지 말고 사용하고 있는 보안그룹인 lauch-wizard-1을 선택해준다.
이전에 태그명으로 설정한 cicd-project-sg도 보인다.
다시 한번 Jenkins에서 Docker서버로 핑 테스트를 해보면 정상 수행되는 것을 확인할 수 있다.
Docker 서버에서도 Jenkins로 핑 테스트를 하면 정상 수행된다.
🌭 AWS EC2에 Jenkins 서버 설치
java --version
git --version
mvn --version
본격적으로 Jenkins 서버를 설치해보도록 하자
Java는 설치되어 있어 버전이 나오지만 Git과 Maven는 포함되어 있지 않아 뜨지 않는다.
이를 먼저 설치해보려고 한다.
sudo amazon-linux-extra install epel -y
cd /opt
ls -ltr
sudo wget https://mirror.navercorp.com/apache/maven/maven-3/3.9.6/binaries/apache-maven-3.9.6-bin.tar.gz
sudo tar -xvf apache-maven-3.9.6-bin.tar.gz
sudo amazon-linux-extra install epel -y : 그 전에 현재 쓰고 있는 아마존 리눅스에 확장 패키지를 설치한 상태에서 진행하자.
확장 패키지를 설치하는 목적은 현재 사용하고 있는 리눅스에 추가적인 디펜던시 패키지들을 다 설치할 수 있다는 특징 때문에 다른 작업 하시기 이전에 먼저 진행해 주는게 좋다.
Maven을 설치하기 위해 디렉토리를 opt로 이동한다. (Liunx의 각종 프로그램들이 설치될 수 있는 폴더)
Maven의 다운로드는 wget 이라는 명령어를 가지고 실행할 수 있다.
다운로드 후에는 tar-xvf라는 옵션으로 파일을 압축을 해제해준다.
압축 후 ls 명령어로 확인해보면 apache-maven-3.8.6-bin.tar.gz maven 폴더가 생긴 것을 확인할 수 있다
sudo mv apache-maven-3.8.6-bin.tar.gz maven
cd maven/
해당 폴더명이 너무 길어 maven으로 짧게 바꿔주었다.
vi ~/.bash_profile
M2_HOME=/opt/maven
PATH=$PATH/$M2_HOME/bin환경 설정을 위해 홈디렉토리에 bach_profile을 vi 에디터로 추가해주었다.
이렇게 하면 어떤 디렉토리에 이동하여도 하시더라도 정상적으로 메이븐에 있는 명령어 사용이 가능하다.
source ~/.bash_profile
mvn --version
작업되어 있는 코드를 실제로 반영하려면 로그아웃 하셨다가 다시 접속하시거나 아니면 source 라는 명령어를 가지고 환경 변수와 설정을 업데이트할 수 있다.
sduo yum install -y git
Git은 아직 설치가 안되어 있는 상황이기에 Git도 설치하였다.
sudo wget -O /etc/yum.repos.d/jenkins.repo https://pkg.jenkins.io/redhat-stable/jenkins.repo
sudo rpm --import https://pkg.jenkins.io/redhat-stable/jenkins.io.key
sudo yum install frontconfig java-11-openjdk
설치를 진행하기에 앞서 Jenkins 공식 사이트에 가면 현재 사용하고 있는 레파지토리에 Jenkins 관련된 패키지가 존재하지 않을 수 있다.
udo wget -O /etc/yum.repos.d/jenkins.repo https://pkg.jenkins.io/redhat-stable/jenkins.repo: 그래서 wget 이라는 명령을 가지고 Jenkins에 설치할 수 있는 레파지토리를 다운로드 받는다.
udo rpm --import https://pkg.jenkins.io/redhat-stable/jenkins.io.key: 키도 정상적으로 임포트해서 등록을 한다.
sudo yum install frontconfig java-11-openjdk: Java 11 OpenJDK 라고 되어있는데, 이 버전도 현재 사용하고 있는 버전과 호환성 문제로 설치에 오류가 발생할 수 있기에 JDK 자체도 버전을 변경한 상태에서 진행하자.
sudo amazon-linux-extras install java-openjdk11
sudo yum install frontconfig java-11-openjdk로 했더니 마지막에 sudo amazon-linux-extras install java-openjdk11 명령어로 다시 실행하라 해서 해당 명령어로 설치를 진행하였다.
sudo /usr/sbin/alternatives --config java
java --version
sudo yum install jenkins
sudo /usr/sbin/alternatives --config java : 지금 두 가지 JDK가 같이 설치되어 있기 때문에 버전을 바꿔 주어야 한다.
최근에 설치한 JDK인 2번으로 다시 설정해주었다.
설정이 끝났다면 젠킨스 다운로드 받는 명령어를 입력해준다.
sduo systemctl status jenkins
sduo systemctl start jenkins
젠킨스가 실행 중인지 status로 확인해보고, inactive 상태이면 start 명령어로 실행해준다.
현재 Jenkins는 8080포트를 이용하므로 웹브라우저로 가서 보안그룹에 8080포트를 추가하여 외부에서 접속할 수 있는 상태로 만들어준다.
보안그룹을 이동하여 인바운드 규칙 편집을 눌러주고
규칙 추가를 눌러준다.
사용자 지정 TCP, 8080번 포트, 접속할 수 있는 범위는 어디든 접속할 수 있게 0.0.0.0/0을 선택해준다.
[퍼블릭 IP주소]:8080
보안 그룹을 설정했으므로 퍼블릭 IP주소를 가지고 8080 포트로 젠킨스 접속이 가능하다.
처음 들어가면 Administrator password를 입력하라고 되어있는데, 이를 확인하기 위해 다시 ssh창으로 이동한다.
sudo cat /var/lib/jenkins/secrets/initialAdminPassword
/var/lib/jenkins/secrets/initialAdminPassword 파일을 cat 명령어를 입력하면 초기 패스워드를 출력한다.
모든 플러그인을 사용할 수 있도록 install suggested plugins를 선택해주면
설치가 진행된다.
관리가 계정을 추가해주면
정상 접속된다.
🍿 AWS EC2에 Docker 서버 설치
sudo amazon-linux-extra install epel -y
인스턴스 도커 서버로 이동한 다음, 먼저 할 작업은 아마존 리눅스 확장 패키지를 설치한다.
sudo yum install –y docker
도커 설치 명령어를 입력한다.
docker --version
docekr version
sudo systemctl enable docker
sudo systemctl start docker
sudo systemctl status docker
설치가 끝나고 도커 버전 확인 명령어를 입력한다.
version에 --가 붙지 않으면 클라이언트 버전과 서버 버전이 표시가 된다.
현재 클라이언트 서버 버전은 확인이 가능하나 서버 버전이 확인이 되지 않는 이유는 docker 데몬이 실행되지 않았기 때문이다.
도커 데몬을 실행시켜주고
sudo docker version
버전을 확인해보면 서버와 클라이언트 모두 버전 확인이 가능하다.
whoami
sudo usermod –aG docker ec2-user
매번 관리자 권한을 사용하기 위해 sudo 라는 명령어를 넣을 수 없기 때문에 ec2-user 사용자에게 docker 그룹을 추가하는 역할을 한다.
docker version
ssh 접속을 끊고 다시 들어가면 ec2-user 사용자가 docker version을 확인이 가능해졌다.
🥓 AWS EC2에 Tomcat 서버 설치
sudo amazon-linux-extras install epel -y
먼저 다른 인스턴스와 동일하게 아마존 확장 패키지를 설치한다.
cd /opt
wget https://mirror.navercorp.com/apache/tomcat/tomcat-9/v9.0.68/bin/apache-tomcat-9.0.68.tar.gz
opt란 폴더에 톰켓 압축 파일을 다운받는다.
sudo tar –xvzf apache-tomcat-9.0.68.tar.gz
다운 받은 파일을 압축 해제한 후
chmod +x /bin/startup.sh
chmod +x /bin/shutdown.sh
압축 해제 한 폴더로 이동하여 빈 디렉토리 파일 중에서 startup 이란 파일과 shutdown 이란 파일을 실행 권한을 포함시켜준다.
sudo ./bin/startup.sh
톰켓 서버를 기동시켜 준다.
톰켓 웹서버를 인스턴스의 퍼블릭 ip주소와 8080 포트번호로 접속이 가능해졌다.
현재 Managet App에 접속하려고 하면 403 Access Denied 가 뜸으로 톰켓의 context 수정이 필요하다.
sudo vi ./webapps/manager/META-INF/context.xml
ssh로 이동하여 톰켓 폴더의 /webapps/manager/META-INF/context.xml를 vi 에디터로 수정해줘야 한다.
주석 처리 해준 부분은 접속할 수 있는 경로를 127.0.0.1로 되어있는 것을 모든 IP주소에서 접속 가능하도록 변경해주었다.
sudo vi ./webapps/host-manager/META-INF/context.xml
마찬가지로 톰켓 폴더의 /webapps/host-manager/META-INF/context.xml를 vi 에디터로 수정해준다.
주석 처리 해준 부분은 접속할 수 있는 경로를 127.0.0.1로 되어있는 것을 모든 IP주소에서 접속 가능하도록 변경해주었다.
sudo vi ./conf/tomcat-usrs.xml
다음으로 사용할 수 잇는 계정을 추가해보자.
/conf/tomcat-usrs 내용을 vi 에디터로 계정을 추가해주었다.
여기선 Managet App에tomcat 유저네임, tomcat 패스워드로 접속 가능하다.
sudo ./bin/shutdown.sh
sudo ./bin/startup.sh
톰켓 서버를 종료 후 시작해주고 다시 웹브라우저로 접속해보자.
톰켓 웹브라우저에서 Managet App을 눌러 아이디와 패스워드를 tomcat이라고 입력하면
정상적으로 접속이 가능해졌다.
🍳 AWS EC2에 Ansible 서버 설치
sudo amazon-linux-extras install epel -y
먼저 아마존 확장패키지를 설치한다.
sudo yum install –y ansible
그 다음에 엔서블 서버를 설치한다.
cd /etc/ansible
ls -al
/etc/ansible로 이동하면 hosts 파일이 있다.
Ansible에서 관리하고자 하는 hosts 파일에 두 가지 서버를 등록해보자.
sudo vi hosts
[localhost]
localhost
[docker]
docker-server 사설 IP주소
[tomcat]
tomcat-server 사설 IP주소vi 에디터로 hosts 파일을 열고 docker 서버와 tomcat 서버 자기 자신인 ansible 서버를 등록하였다.
ssh ec2-user@[ec2_ip_address]
ssh-keygen -t rsa
docker 서버와 tomcat 서버에 접속을 시도했으나 Permission denined가 떴다.
이유는 접속하려고 하는 ansible 서버에서 EC2에 있는 tomcat 서버와 docker 서버를 접속하기 위해서는 키를 복사해서 넘겨주시는 부분이 필요한데 현재 ansible에서 가지고 있는 어떤 키 값을 tomcat과 docker 서버에서 사용할 수 있도록 허용이 되지 않은 상태이기 때문이다.
ssh-keygen 명령어로 키를 하나 생성한다. (rsa 알고리즘 사용)
cd .ssh
ls -al
ssh 폴더로 이동하여 파일 목록을 확인해보면 id_rsa,is_rsa.pub,authorized_keys를 발견할 수 있다.
id_rsa은 pricate key 값이고, id_rsa.pub은 public key 값이다.
이 public key 값을 docker 서버와 tocat 서버에 복사한다.
그러면 접속할 때 패스워드 없이 바로 접속 가능하도록 설정이 가능해진다
cat id_ras.pub //ansible 서버
vi authorized_keys //docker 서버cat id_ras.pub //ansible 서버
vi authorized_keys //tomcat 서버
id_ras.pub 파일에 있는 public key를 복사하여 docker 서버와 ansible 서버 각각에 authorized_keys vi 에디터를 열어 붙여넣는다.
ssh ec2-user@[ec2_ip_address]
ansible에서 docker로 ssh 접속이 가능해진다.
ansible docker -m ping
ansible tomcat -m ping
핑 테스트도 무리 없이 잘 진행된다.
hosts에 docker 와 tomcat 그룹을 만들었으니 해당 그룹의 ip주소로 통신이 가능한 것이다.
ansible localhost -m ping
localhost 그룹으로 핑테스트 하면 UNREACHABLE이 발생한다.
자기자신이라고 예외없다. public key를 authorized_keys에 추가해야 한다.
cat id_rsa.pub
vi authorized_keys
id_rsa.pub 의 저장된 키값을 복사하여 authorized_keys에 추가해주었다.
ansible localhost -m ping
ansible all -m ping
핑 테스트가 정상적으로 수행된다.
🥞 AWS EC2에 SonarQube 설치
소나큐브는 기존에 사용하셨던 다른 인스턴스 타입처럼 t2.micro로 선택해서 실행하면 리소스 부족으로 정상적으로 서비스가 실행이 안되는 경우가 있다. 꼭 t2.small로 변경하길 바란다.
문제는 프리티어를 사용해도 과금이 될 수 있는 우려가 있으니 조심해서 써야 한다.
cd /opt
ls -al
sudo mkdir sonarqube
cd sonarqube/
pwd
sudo wget https://binaries.sonarsource.com/Distribution/sonarqube/sonarqube-7.6.zip
sudo unzip sonarqube-7.6.zip
sonarqube 다운을 받고 압축을 해제한다.
sudo chown -R ec2-user:ec2-user /opt/sonarqube/
sonarqube는 엘라스틱 서치라는 서비스와 같이 연관해서 사용하고 있는데 루트 권한이 아닐 경우에 해당하는 이 서비스를 사용할 수 없다고 오류가 발생할 수 있다.
그래서 ec2-user에 이 sonarqube를 사용할 수 있도록 소유권을 바꿔 주었다.
cd bin
ls -al
cd windows-x86-64
sonar.sh status
sonar.sh start
sonar.sh status
bin 이라는 폴더를 보면 sonarqube를 실행할 수 있는 명령어가 각 플랫폼 별 제공되고 있다.
리눅스 버전, 맥OS 버전, 윈도우즈 버전이 있는데 나는 윈도우 pc 버전이기 때문에 해당 폴더로 이동하여 명령어를 실행하였다.
sonaqube가 9000번 포트로 접속할 수 있도록 인바운드 규칙도 추가해주었다.
사용자 지정 TCP, 9000, 0.0.0.0/0으로 9000번 포트로 누구든 접속 가능하게 하였다.
sonaqube 인스턴스의 퍼블릭 IP주소와 9000번 포트로 접속하면 SonqQube 서버 웹브라우저 접속이 가능해진다.
토큰 발급 후 Jenkins 연동 시 사용도 가능하다
🧇 Jenkins를 이용하여 Tomcat 서버에 배포
Jenkins 프로젝트를 생성하고 Tomcat 서버와 Docker 서버에 배포를 해보자
대시보드 -> Jenkins 관리 -> Plugin 으로 이동하여 Maven Integration Plugin을 설치한다.
Deploy to container Plugin도 설치해준다.
대시보드 -> Jenkins 관리 -> Tools로 이동하여 하단으로 내려가면 Maven installations라는 메뉴가 있다.
메이븐을 이미 설치하였기 때문에 install automatically 체크박스는 해제해주었다.
여기에 사용하고자 하는 메이븐의 이름을 적고, 위치를 적어준다.
NAME은 Maven 3.8.6으로 하였고, MAVEN HOME은 /opt/maven으로 지정해주었다.
Jenkins ssh 클라이언트로 돌아가 한번 더 확인해보면 pwd명령어로 확인해보았을 때 /opt/maven이라고 뜨면 그 위치가 Maven 홈 디렉토리라고 보면 된다.
새로운 Item을 클릭하여 아이템을 생성해보자.
이름은 My-Tomcat-project로 생성하였다.
구성에서 소스 코드 관리에 가져올 Git 주소를 적어준다.
만약 public이 아닌 private 으로 되어있다면 Credentials에 암호를 적어준다.
그리고 해당 레포지터리는 master가 아닌 main 브런치임으로 변경해주었다.
Build에 Root POM은 pom.xml, Goals and options엔 clean complie package를 적어준다.
맨 밑에 내려가면 빌드 후 조치가 있다.
빌드 후 조치 추가를 눌러주고 Deploy war/ear to a container를 클릭해준다.
WAR/EAR files엔 **/*.war를 적어주고, Context path에는 .을 입력해주었다.
Add Container 를 눌러 Tomcat 9.x Remote를 클릭해주고
Credentials를 Add를 눌러 추가해준다.
Username에 deployer라는 계정을 가지고 접속을 할 것이고, 패스워드도 deployer라고 지정을 하였다.
ID는 deployer_user1이라고 임시로 쓰겠다.
Tomcat URL은 Tomcat 인스턴스의 퍼블릭 IP주소와 8080포트로 웹브라우저를 접속함으로 http://[tomcat 인스턴스 퍼블릭 IP주소]:8080라고 적어주었다.
지금 빌드를 눌러 빌드를 진행하면
콘솔에 SUCCESS라고 뜨며 빌드 성공하였다.
cd /var/lib/jenkins
ls -al
Teminus로 돌아가 Jenkins ssh 클라이언트를 확인해보면 workspace가 보인다.
cd workspace/
ls -al
cd My-Tomcat-Project/
ls -al
workspace 폴더로 이동해 목록을 보면 My-Tomcat-Project 폴더가 보인다.
폴더 안에는 깃허브에서 가져온 코드, target이란 폴더에 의해 만들어진 패키징 파일을 확인할 수 있다.
톰켓 서버에 접속하여 확인해보면 /hello-world 가 잘 배포된 것을 확인할 수 있다.
클릭해보면 결과물이 잘 배포된 것을 확인할 수 있다.
🍞 Jenkins를 이용하여 Docker 서버에 배포
먼저 도커 서버에 배포하기 위해서 SSH Plugin을 설치해줘야 한다.
Publish Over SSH를 설치해준다.
ssh ec2_user@[docker 인스턴스 사설 IP주소]
Jenkins에서 Docker 서버로 ssh 접속을 시도하지만, Permission denined가 뜬다.
ssh-keygen -t rsa
Jenkins에서 rsa 알고리즘으로 키를 만들어 등록한 다음에
cd .ssh
ls -al
cat id_rsa.pub
ssh 폴더의 id_rsa.pub라는 파일 속 public key 값을 복사하여
ls -al
vi suthorized_keys
cat authorized_keys
Docker 서버의 ssh 폴더 속 authorized_keys 파일에 복사한 public key를 붙여넣는다.
ssh ec2-user@[docker 인스턴스 사설 IP주소]
Jenkins 서버에서 ssh로 Docker 서버로 정상적으로 접속이 가능해진다.
cat id_rsa
마찬가지로 Dcoker 서버의 ssh 폴더의 id_rsa 파일을 열면 private key가 나온다.
대시보드 -> Jenkins 관리 -> System에 SSH Server를 추가해줘야 한다.
이름은 docker-server, 호스트네임은 Docker 서버의 사설 IP주소, 유저네임은 ec2-user라고 적어주고 Remote Directory는 . 루트로 설정해주었다.
밑에 고급을 눌러
Key값을 입력해줘야 하는데, 방금 전 id_rsa파일에 있던 private key를 복사하여 붙여넣어주었다.
설정이 끝났으면 새로운 아이템을 만들어준다.
이름은 My-Docker-Project이고,
처음에 만들었던 My-Tomcat-Project를 카피하여 사용하겠다.
다른 것은 똑같이 쓰되 빌드 후 조치로 내려가 이전에 썼던 Deploy war/ear to a containter를 삭제해주고, Send build artifacts over SSH을 선택해주었다.
SSH Server의 Name은 docker-server를 선택해주었고, Transfer Set에 Sorce files는 targer/*.war, Remove prefix는 target이라고 적어주었다.
Remote directory는 . 루트로 설정하고 저장하였다.
설정이 끝났으니 지금 빌드를 눌러 실행해준다.
콘솔을 확인해보니 성공하였다.
hello-world.war 파일이 홈 디렉토리에 정상적으로 전달되었다.
해당 Docker 서버에서는 도커 이미지와 컨테이너를 사용할 수 있다.
Dockerfile을 하나 만들어놓고 그 만들어진 도커 파일을 Jenkins에서 실행할 수 있도록 만들어보자
Dockerfile에 vi 에디터로 진입하여
FROM tomcat:9.0
COPY ./hello-world.war /user/local/tomcat/webapps으로 생성해 주었다.
다시 방금 작업했던 Jenkins의 My-Docker-Project로 돌아가 구성 정보를 수정해보자
빌드 후 조치까지 내려가서 아깐 생략하고 넘어간 Exec command를 추가해주었다.
docker build -tag=cicd-project -f Dockerfile .;
docker run -p 8080:8080 -name mytomcat cicd-project:latest
지금 빌드로 실행해주고
콘솔을 확인해보면 UNSTABLE이 떴다.
docker ps -a
docker iamges
아마 톰켓 서버를 다운 받는 부분에서 타임아웃이 발생한 것이 아닐까 라는 추측이 든다.
확인해보면 이미지도 잘 생성되고, 컨테이너도 잘 생성이 되었는데 콘솔 내용을 확인해보면 시간초과로 UNSTABLE이 뜬 듯 하다.
docker stop [컨테이너 ID]
docker rm [컨테이너 ID]
docker rmi [이미지명]
만들어진 컨테이너와 이미지는 삭제해주고
Exec command를 살짝 수정해주었다.
docker build -tag=cicd-project -f Dockerfile .;
docker run -d -p 8080:8080 -name mytomcat cicd-project:latestforeground로 실행 중이었던 것을 background로 실행해주는 옵션 -d를 추가해주었다.
변경 후 다시 빌드하여 콘솔을 확인해보면 SUCCESS가 떴다.
docker 이미지와 컨테이너도 정상적으로 만들어졌다.
출처
