Jlaner 개발기록 8 배포 AWS (DOCKER)

이번 포스팅은 저번에 이어서 배포를 진행하도록 하겠다.

이번 포스팅은 넘어갈까 싶었다. 글을 쓰던 도중 중간까지 글을 작성했는데 글이 날아갔다... 자동 임시저장이 있지만 페이지가 나가지고 새로고침까지 돼서 글들이 사라졌다.... 다시 작성할 생각에 아찔한데 다시 천천히 작성해 보도록 하겠다.

 

우선 무중단 배포 전략에 대해서이다. 이번 포스팅에서는 저번에 하다가 하지 못한 도커 배포만 진행해보고 다음 포스팅에 무중단 배포를 하는 것을 포스팅할 생각인데 지금 무중단 배포 전략을 설명하는 이유는 배포하면서 생각해야 할 부분이 있기 때문이다.

무중단 배포 전략으로는 rolling, canary, blue-green 전략 3가지가 있다. 필자가 선택한 전략은 블루 그린이다.

이유로는 rolling은 배포시 각 연결된 서비스들 예시로 데이터베이스, 레디스 등등 애플리케이션을 구성하게 되는 서비스들을 각각 버전업을 해주는 것이다. 구성하는 방법을 찾아보았을 때 설정이 어려워서 추후에 구성하고 소개할 수 있는 레벨이 되면 해보도록 하겠다.

다음은 canary이다. canary는 구버전의 서버와 신 버전의 서버를 구성하고 일부 트래픽을 새 버전으로 분산해 에러 여부 판단하고 모니터링하는 배포 방식이다.이 배포 방식도 설정이 어렵다. 이후 추후에 레벨이 된다면 구성해 보도록 하고 필자가 선택한 배포 방식은 블루 그린이다.

구 버전인 블루와 새로운 버전인 그린으로 인스턴스를 구성하고 로드밸런서를 통해 새로운 버전으로 전환하는 배포 방식이다.

이 방식을 사용해서 진행하도록 하겠다.

이제 블루 그린 전략을 선택했으니 배포시에 어떤 것으로 배포할지 선택해야 한다.

EBS로 2개의 환경을 구성해 블루와 그린으로 생성하고 생성한 인스턴스를 CodePipeline과 같은 도구를 사용해서 배포 파이프라인을 구성할 수 있다.

다음은, EC2 인스턴스를 구성해 하나의 인스턴스에서 컨테이너를 2개를 띄워서 엔진엑스로 로드 밸런싱을 통한 무중단 배포를 할 수 있다.

 

무중단 배포에 대해서 당장 할 것이 아닌데 설명한 이유는 지금 포스팅은 저번에 도커 컴포즈로 컨테이너를 띄우는 것이 제대로 구성하지 못해서 실패했기 때문에 EBS를 통해 배포하는 것이 목표이며 여러 설정이 간단하다는 장점을 지녔고 ElasticBeanstalk 특성 상 이벤트(github actions CD)가 발생하면 EC2가 삭제되었다가 새롭게 생성이 되기 때문에 EC2 서버 내에 docker 형태로 넣고, 볼륨 마운트 하는 것이 쉽지 않다는 지녔기 때문에 고민이 됐다 설정이 번거롭지만 단일 인스턴스로도 할 수 있는 EC2로 할 것인가 EBS를 선택할 것인가 이번 포스팅에서 EBS를 통한 도커 배포를 해보고 생각을 해보며 다음 포스팅에서 선택한 방법으로 무중단 배포를 해보도록 하겠다.

 

우선 도커를 배포해야하니 AWS에 접속해서 EBS에서 환경을 만들어주자.

사전에 VPC를 생성해주자.

별 다른 설정 없이 기본적인 VPC만 설정했다.

다음은 키페어를 생성해 주자.

이름을 넣고 RSA 유형의 .pem 형식의 키를 저장하게 되는데 이는 쉘 접속할 때 사용되니 저장해 두고 사용해야 한다.

이제 EBS를 구성해 보자.

 

 

이전 환경들은 모두 깔끔히 삭제했으니 새로 만들어 구성하자.

 

전에 자바로 구성했을 때와 비슷하다.

이외에 추가로 특별히 구성한 것은 없다.

이제 docker-compose를 업로드하고 진행해 보자.

 

업로드했을 때 오류가 발생했다. 발생한 이유를 확인해 보자.

전체 로그를 다운로드하여서 확인해 보았다.

전체 로그 중 eb.stdouterr.log를 확인해 보면 컨테이너가 실행되는지에 대한 로그를 확인할 수 있다.

redis  | exec /usr/local/bin/redis-server: exec format error
mysql  | exec /usr/local/bin/docker-entrypoint.sh: exec format error
spring-app-1  | exec /usr/java/openjdk-21/bin/java: exec format error
spring-app-1  | exec /usr/java/openjdk-21/bin/java: exec format error
spring-app-1  | exec /usr/java/openjdk-21/bin/java: exec format error
spring-app-1  | exec /usr/java/openjdk-21/bin/java: exec format error
spring-app-1  | exec /usr/java/openjdk-21/bin/java: exec format error
spring-app-1  | exec /usr/java/openjdk-21/bin/java: exec format error
spring-app-1  | exec /usr/java/openjdk-21/bin/java: exec format error
spring-app-1  | exec /usr/java/openjdk-21/bin/java: exec format error
spring-app-1  | exec /usr/java/openjdk-21/bin/java: exec format error

 

spring-app의 로그가 많은 이유는 restart를 always로 설정했기 때문이다.

 

다음은 docker-compose-events.log이다.

2024-09-03 18:15:25.865583 container create b776a2682af59a1fb27164e69471e4e61bc5b392a1310b6067d5cfef9cb7342d (image=hanjihoon0315/docker-mysql, name=mysql)

2024-09-03 18:15:25.869808 container create c217aa7eabfb06d93bf450e65c172adcbc4bee69120660bfeaf05ebd41126e24 (image=hanjihoon0315/docker-redis, name=redis)

2024-09-03 18:15:25.895267 container create 959a56077ae764d9f06b3d13e84b95b0c7d3a33f9c3443bd7583007466ee0cce (name=current-spring-app-1, image=hanjihoon0315/docker-springboot)

2024-09-03 18:15:27.434833 container start b776a2682af59a1fb27164e69471e4e61bc5b392a1310b6067d5cfef9cb7342d (image=hanjihoon0315/docker-mysql, name=mysql)

2024-09-03 18:15:27.444955 container start c217aa7eabfb06d93bf450e65c172adcbc4bee69120660bfeaf05ebd41126e24 (image=hanjihoon0315/docker-redis, name=redis)

2024-09-03 18:15:27.897238 container die b776a2682af59a1fb27164e69471e4e61bc5b392a1310b6067d5cfef9cb7342d (name=mysql, execDuration=0, exitCode=1, image=hanjihoon0315/docker-mysql)

2024-09-03 18:15:28.067044 container start 959a56077ae764d9f06b3d13e84b95b0c7d3a33f9c3443bd7583007466ee0cce (image=hanjihoon0315/docker-springboot, name=current-spring-app-1)

2024-09-03 18:15:28.180102 container die c217aa7eabfb06d93bf450e65c172adcbc4bee69120660bfeaf05ebd41126e24 (exitCode=1, image=hanjihoon0315/docker-redis, name=redis, execDuration=0)

2024-09-03 18:15:28.446458 container die 959a56077ae764d9f06b3d13e84b95b0c7d3a33f9c3443bd7583007466ee0cce (exitCode=1, execDuration=0, image=hanjihoon0315/docker-springboot, name=current-spring-app-1)

2024-09-03 18:15:28.976546 container start 959a56077ae764d9f06b3d13e84b95b0c7d3a33f9c3443bd7583007466ee0cce (name=current-spring-app-1, image=hanjihoon0315/docker-springboot)

2024-09-03 18:15:29.336548 container die 959a56077ae764d9f06b3d13e84b95b0c7d3a33f9c3443bd7583007466ee0cce (exitCode=1, image=hanjihoon0315/docker-springboot, name=current-spring-app-1, execDuration=0)

2024-09-03 18:15:29.717605 container start 959a56077ae764d9f06b3d13e84b95b0c7d3a33f9c3443bd7583007466ee0cce (image=hanjihoon0315/docker-springboot, name=current-spring-app-1)

2024-09-03 18:15:30.055970 container die 959a56077ae764d9f06b3d13e84b95b0c7d3a33f9c3443bd7583007466ee0cce (execDuration=0, exitCode=1, image=hanjihoon0315/docker-springboot, name=current-spring-app-1)

2024-09-03 18:15:30.484060 container start 959a56077ae764d9f06b3d13e84b95b0c7d3a33f9c3443bd7583007466ee0cce (image=hanjihoon0315/docker-springboot, name=current-spring-app-1)

2024-09-03 18:15:30.840729 container die 959a56077ae764d9f06b3d13e84b95b0c7d3a33f9c3443bd7583007466ee0cce (name=current-spring-app-1, execDuration=0, image=hanjihoon0315/docker-springboot, exitCode=1)

2024-09-03 18:15:31.700733 container start 959a56077ae764d9f06b3d13e84b95b0c7d3a33f9c3443bd7583007466ee0cce (image=hanjihoon0315/docker-springboot, name=current-spring-app-1)

2024-09-03 18:15:32.141243 container die 959a56077ae764d9f06b3d13e84b95b0c7d3a33f9c3443bd7583007466ee0cce (name=current-spring-app-1, exitCode=1, execDuration=0, image=hanjihoon0315/docker-springboot)

2024-09-03 18:15:33.642183 container start 959a56077ae764d9f06b3d13e84b95b0c7d3a33f9c3443bd7583007466ee0cce (name=current-spring-app-1, image=hanjihoon0315/docker-springboot)

2024-09-03 18:15:33.998444 container die 959a56077ae764d9f06b3d13e84b95b0c7d3a33f9c3443bd7583007466ee0cce (exitCode=1, image=hanjihoon0315/docker-springboot, name=current-spring-app-1, execDuration=0)

2024-09-03 18:15:37.218686 container start 959a56077ae764d9f06b3d13e84b95b0c7d3a33f9c3443bd7583007466ee0cce (image=hanjihoon0315/docker-springboot, name=current-spring-app-1)

2024-09-03 18:15:37.607252 container die 959a56077ae764d9f06b3d13e84b95b0c7d3a33f9c3443bd7583007466ee0cce (execDuration=0, exitCode=1, image=hanjihoon0315/docker-springboot, name=current-spring-app-1)

2024-09-03 18:15:44.055164 container start 959a56077ae764d9f06b3d13e84b95b0c7d3a33f9c3443bd7583007466ee0cce (image=hanjihoon0315/docker-springboot, name=current-spring-app-1)

2024-09-03 18:15:44.507785 container die 959a56077ae764d9f06b3d13e84b95b0c7d3a33f9c3443bd7583007466ee0cce (execDuration=0, exitCode=1, image=hanjihoon0315/docker-springboot, name=current-spring-app-1)

2024-09-03 18:15:57.265058 container start 959a56077ae764d9f06b3d13e84b95b0c7d3a33f9c3443bd7583007466ee0cce (image=hanjihoon0315/docker-springboot, name=current-spring-app-1)

2024-09-03 18:15:57.620678 container die 959a56077ae764d9f06b3d13e84b95b0c7d3a33f9c3443bd7583007466ee0cce (execDuration=0, exitCode=1, image=hanjihoon0315/docker-springboot, name=current-spring-app-1)

2024-09-03 18:16:23.243401 container start 959a56077ae764d9f06b3d13e84b95b0c7d3a33f9c3443bd7583007466ee0cce (name=current-spring-app-1, image=hanjihoon0315/docker-springboot)

2024-09-03 18:16:23.595737 container die 959a56077ae764d9f06b3d13e84b95b0c7d3a33f9c3443bd7583007466ee0cce (execDuration=0, exitCode=1, name=current-spring-app-1, image=hanjihoon0315/docker-springboot)

2024-09-03 18:17:14.804173 container start 959a56077ae764d9f06b3d13e84b95b0c7d3a33f9c3443bd7583007466ee0cce (image=hanjihoon0315/docker-springboot, name=current-spring-app-1)

2024-09-03 18:17:15.135512 container die 959a56077ae764d9f06b3d13e84b95b0c7d3a33f9c3443bd7583007466ee0cce (exitCode=1, name=current-spring-app-1, execDuration=0, image=hanjihoon0315/docker-springboot)

2024-09-03 18:18:15.177878 container start 959a56077ae764d9f06b3d13e84b95b0c7d3a33f9c3443bd7583007466ee0cce (name=current-spring-app-1, image=hanjihoon0315/docker-springboot)

2024-09-03 18:18:15.587509 container die 959a56077ae764d9f06b3d13e84b95b0c7d3a33f9c3443bd7583007466ee0cce (execDuration=0, exitCode=1, name=current-spring-app-1, image=hanjihoon0315/docker-springboot)

 

컨테이너가 start 되고 die 되는 것을 확인할 수 있다.

왜 그런지 자세한 오류를 알아보기 위해서 eb-engine.log를 확인하면 이유를 찾을 수 있다.

mysql The requested image's platform (linux/arm64) does not match the detected host platform (linux/amd64/v4) and no specific platform was requested 
 Container mysql  Created
 redis The requested image's platform (linux/arm64) does not match the detected host platform (linux/amd64/v4) and no specific platform was requested 
 Container redis  Created
 Container current-spring-app-1  Creating
 spring-app The requested image's platform (linux/arm64/v8) does not match the detected host platform (linux/amd64/v4) and no specific platform was requested 
 Container current-spring-app-1  Created

 

도커에 생성한 이미지와 ec2의 플랫폼 맞지 않아서 생긴 오류이다.

에러를 찾는데도 시간이 꽤나 걸렸지만 알아냈으니 해결할 수 있다.

해결 방법은 도커 이미지를 빌드할 때 해당하는 플랫폼의 이미지로 빌드하는 방법과 이미지를 실행하게 될 때 실행 시에 플랫폼을 정해주는 방법이 있지만 필자는 이미지를 amd64 이미지로 빌드해서 사용하는 것으로 정했다.

docker build --platform linux/amd64 -t docker-redis-aws -f dockerfile.redis .

이와 같은 방법으로 새로운 이미지를 빌드했다. 빌드하기 이전에 사용하던 이미지는 삭제하고 새롭게 이미지를 생성했다. spring-app과 mysql도 이와 같이 새로 빌드했다.

따로 코드를 바꾼 것도 아니며 추후에 CI/CD를 다시 하게 될 때는 도커파일로 이미지 빌드하는 곳에 amd64로 빌드할 수 있도록 하겠다.

지금은 직접 빌드해서 사용했다.

빌드 후에 아래와 같이 이미지에 태그를 달아 허브에 push 했다.

hanjihoon@hanjihun-ui-MacBookAir project % docker tag docker-redis-aws hanjihoon0315/docker-redis     
hanjihoon@hanjihun-ui-MacBookAir project % docker push hanjihoon0315/docker-redis

 

이후 환경을 다시 빌드해서 실행해 보도록 하자.

 

상태도 OK이고 접속해 보았지만 아래와 같이 연결할 수 없었다. 당황스러웠지만 무엇이 문제인지 ec2 쉘에 접속해서 확인하기로 했다.

 

도커가 실행되는지 docker ps -a로 확인을 해보았을 때 

15d3c3b4992e   hanjihoon0315/docker-springboot   "java -jar /app.jar …"   4 hours ago   Up 4 hours               0.0.0.0:8080->8080/tcp, :::8080->8080/tcp   current-spring-app-1
975a33702aee   hanjihoon0315/docker-redis        "redis-server /data/…"   4 hours ago   Up 4 hours               0.0.0.0:6379->6379/tcp, :::6379->6379/tcp   redis
e9dcf9574ef6   hanjihoon0315/docker-mysql        "docker-entrypoint.s…"   4 hours ago   Exited (1) 4 hours ago                                               mysql
[root@ip-10-0-22-197 ec2-user]#

 

이와 같이 잘 실행되는 것을 확인할 수 있지만 Mysql은 어떤 문제인지 실행되지 않았다.

로그를 확인해 보자.

2024-09-03T23:43:15.385301516Z container oom e9dcf9574ef611fa89dd5fecc23571c373681c3710973ffca8bfc7409b99e7a2 (com.docker.compose.config-hash=cb7fef1a49428f279c7179ee40dd630d34ce09693910dc39f216913ffe1622d7, com.docker.compose.container-number=1, com.docker.compose.depends_on=, com.docker.compose.image=sha256:a82a8f162e188e0df15b0d2d90c6e9e973af8e88a6cb74b8052122ae5e02325c, com.docker.compose.oneoff=False, com.docker.compose.project=current, com.docker.compose.project.config_files=/var/app/current/docker-compose.yml, com.docker.compose.project.working_dir=/var/app/current, com.docker.compose.service=mysql, com.docker.compose.version=2.29.1, image=hanjihoon0315/docker-mysql, name=mysql)
2024-09-03T23:43:16.816657491Z network disconnect 89fb61335e7a60c0df933ff787509246c0c18e0793575d1a70a73538998b0aae (container=e9dcf9574ef611fa89dd5fecc23571c373681c3710973ffca8bfc7409b99e7a2, name=current_backend, type=bridge)
2024-09-03T23:43:16.868706587Z volume unmount current_mysql-data (container=e9dcf9574ef611fa89dd5fecc23571c373681c3710973ffca8bfc7409b99e7a2, driver=local)
2024-09-03T23:43:16.873669156Z container die e9dcf9574ef611fa89dd5fecc23571c373681c3710973ffca8bfc7409b99e7a2 (com.docker.compose.config-hash=cb7fef1a49428f279c7179ee40dd630d34ce09693910dc39f216913ffe1622d7, com.docker.compose.container-number=1, com.docker.compose.depends_on=, com.docker.compose.image=sha256:a82a8f162e188e0df15b0d2d90c6e9e973af8e88a6cb74b8052122ae5e02325c, com.docker.compose.oneoff=False, com.docker.compose.project=current, com.docker.compose.project.config_files=/var/app/current/docker-compose.yml, com.docker.compose.project.working_dir=/var/app/current, com.docker.compose.service=mysql, com.docker.compose.version=2.29.1, execDuration=89, exitCode=1, image=hanjihoon0315/docker-mysql, name=mysql)

 

확인해 보면 oom 즉, Out Of Memory 메모리 부족이다. 프리티어를 사용하고 있고 하나의 1기가 인스턴스에 레디스, 스프링 앱, mysql까지 한 번에 실행하다 보니 oom이 생긴 것 같다.

해결 방법으로는 떠오르는 것은 2가지이다.

swap space를 만들어서 처리를 해주던지 아니면 mysql 부분을 뗴어내서 RDS를 구성해 인스턴스를 추가로 구성하는지이다.

지금은 배포되어서 내 프로젝트가 실행이 되어야 하는 게 먼저이기 때문에 무엇이 문제인가를 알아보자.

일단 스프링은 실행 중이고 왜 연결이 되지 않는가에 대해서 시간을 꽤나 잡아먹었었는데 도커는 배포되었고 실행은 잘 되고 있지만 접속이 되지 않는 것이니 우선 보안 그룹으로 이동해 보안 그룹에서 HTTP와 HTTPS의 인바운드 규칙을 모두 열어주었다.

위와 같이 열어주었고 다시 실행했을 때도 되지 않았다.

보안 그룹의 문제는 아닌가?라는 생각이 들었고 EBS 구성을 한번 실패하고 공부할 때 EBS는 엔진엑스를 자체적으로 사용한다는 것을 알게 되었다. 그래서 엔진엑스의 문제인가라는 생각이 들었다 그래서 쉘에서 엔진엑스가 설치가 되어 있는지 확인하고 진행했다.

[root@ip-10-0-22-197 ec2-user]# systemctl status nginx
○ nginx.service - The nginx HTTP and reverse proxy server
     Loaded: loaded (/usr/lib/systemd/system/nginx.service; disabled; preset: disabled)
     Active: inactive (dead)

 

엔진엑스가 dead 실행 중이지 않음을 뜻한다.

root@ip-10-0-22-197 ec2-user]# systemctl status nginx
● nginx.service - The nginx HTTP and reverse proxy server
     Loaded: loaded (/usr/lib/systemd/system/nginx.service; disabled; preset: disabled)
     Active: active (running) since Wed 2024-09-04 00:59:41 UTC; 13s ago
    Process: 6359 ExecStartPre=/usr/bin/rm -f /run/nginx.pid (code=exited, status=0/SUCCESS)
    Process: 6360 ExecStartPre=/usr/sbin/nginx -t (code=exited, status=0/SUCCESS)
    Process: 6376 ExecStart=/usr/sbin/nginx (code=exited, status=0/SUCCESS)
   Main PID: 6407 (nginx)
      Tasks: 3 (limit: 1059)
     Memory: 3.6M
        CPU: 75ms
     CGroup: /system.slice/nginx.service
             ├─6407 "nginx: master process /usr/sbin/nginx"
             ├─6408 "nginx: worker process"
             └─6409 "nginx: worker process"

Sep 04 00:59:41 ip-10-0-22-197.ap-northeast-2.compute.internal systemd[1]: Starting nginx.service>
Sep 04 00:59:41 ip-10-0-22-197.ap-northeast-2.compute.internal nginx[6360]: nginx: the configurat>
Sep 04 00:59:41 ip-10-0-22-197.ap-northeast-2.compute.internal nginx[6360]: nginx: configuration >
Sep 04 00:59:41 ip-10-0-22-197.ap-northeast-2.compute.internal systemd[1]: Started nginx.service >

[root@ip-10-0-22-197 ec2-user]# systemctl enable nginx
Created symlink /etc/systemd/system/multi-user.target.wants/nginx.service → /usr/lib/systemd/system/nginx.service.
[root@ip-10-0-22-197 ec2-user]#

 

엔진엑스를 실행하고 부팅 시 자동으로 시작되도록 구성해 보았다.

이후 도메인에 접속하면 엔진엑스 화면을 확인할 수 있다.

엔진엑스 화면을 확인하면서 든 생각은 정상적으로 인스턴스가 시작되고 있으니 엔진엑스가 라우팅을 하지 못한 문제가 맞았다. 엔진엑스 설정도 안 되어 있을 것이고 애초에 꺼져 있었으니 접속할 수 있을 리 없었다.

엔진엑스는 실행했으니 엔진엑스 설정을 해줘서 라우팅 할 수 있도록 구성해 보자.

갑작스럽게 엔진엑스를 사용하게 되었는데 이번에 설정하고 좀 더 나아가면 이대로 컨테이너만 추가해서 무중단까지 고려하고 있다.

우선 /etc/nginx/nginx.conf 이 엔진엑스 설정 파일을 수정해야 한다.

vi 명령어를 통해 수정해 주었다. 기본 설정 파일에는 server가 있는데 이는 주석처리 하거나 없애도 된다.

	include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*.conf;

#    server {
#        listen       80;
#        listen       [::]:80;
#        server_name  _;
#        root         /usr/share/nginx/html;

        # Load configuration files for the default server block.
#        include /etc/nginx/default.d/*.conf;
#
 #       error_page 404 /404.html;
  #      location = /404.html {
   #     }
#
 #       error_page 500 502 503 504 /50x.html;
  #      location = /50x.html {
   #     }
    #}

 

그 후 원래 기본 설정에는

include /etc/nginx/conf.d/*.conf; 이 부분이 include 되어 있을 텐데 별도로 아래에 

include /etc/nginx/sites-enabled/*.conf;  으로 기입해 주고 저장하고 나와서 해당 디렉터리에 파일을 만들어주면 된다.

*부분은 각자 알아서 이름을 생성하고 .conf로 끝나면 된다. 이 설정이 nginx의 서버 설정으로 적용될 것이다.

필자는 default.conf로 구성했고 구성 파일을 확인해 보자.

server {
    listen       80;
    listen       [::]:80;
    server_name  도메인

    location / {
        proxy_pass http://localhost:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

 

이처럼 구성했다. 

80 포트에서 들어오는 HTTP 요청을 수신해 server_name인 도메인 이름으로 들어오는 요청을 처리한다.

위 설정은 모든 요청을 http://localhost:8080으로 프락시 하여 전달한다.

이외는 헤더 세팅에 대한 부분인데 필자가 사용한 것은 기본적으로 사용하는 것들 사용한 것이다.

이렇게 구성하고 저장을 해주자.

sudo nginx -t

엔진엑스 설정을 테스트해보고 아래와 같이 뜨면 된다.

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

 

이후 엔진엑스 서비스를 재시작하고 다시 접속해 보자.

sudo systemctl restart nginx

 

 

주소를 확인하면 잘 접속이 된다.

 

많이 힘들었다. 중간에 포스팅도 한 번 날아가고 많이는 아니지만 첫 개인 프로젝트 진행하고 공부하며 이것저것 배포해보고 했을 때보단 아는 것이 많고 파이프 라인이나 구조적인 것에 대해 더 이해를 하고 있어서 생각하는 대로 어느 정도 될 줄 알았지만 막상 해보니 안 되고 어려운 게 많았지만 차근차근 풀어나갔다 솔직히 중간에 포기하고 EC2로 쉘에서 내가 도커 실행해서 해버리고 싶다고 생각도 했지만 참아서 EBS도 꼭 사용하고 싶었다 여태 4번은 실패했던 것 같다 자바로 두 번 실패하고 저번에 성공하고 도커로 2번 실패하고 이번에 성공했다.

기쁘기도 하고 감격스럽다. 오류가 생기고 어려운 게 생겨도 지금은 이전보다 더 진취적이고 에러를 찾고 해결법을 찾는 법을 좀 더 효과적으로 다가갈 수 있게 되어 가는 것 같아 만족한다. 항상 예상과 달리 잘 되지 않으면 힘들고 스트레스도 받지만 이렇게 실패하면서 하는 게 더 단단해지고 공부도 스스로 더 하게 되는 것 같아서 열심히 실패하고 열심히 해보려 한다.

아직 완성된 것이 아니다. mysql 부분도 어떤 방법으로 진행할지 진행하며 실패할지도 모르니 할게 많다. mysql 이후에는 CI/CD 쪽 정리하 것이고 CD를 하기 이전에 무중단 배포를 지금 EBS로 진행할지 새로운 EC2로 할지 고민을 해보고 더 좋은 방법으로 소개하도록 하겠다.