Docker - NginX - CertBot

🐋 Docker - NginX - CertBot 🐋

🦐 Intor

과거 EBMK 프로젝트에서 Docker를 동해 CI/CD 와 로드 밸런스를 구축했다.

완전하지는 못했지만 첫 Docker 배포라는 점에서 많은것을 배울 수 있었다.

그리고 이번 MLP 파이널 햡업 프로젝트에서는 더욱 견고한 배포 파이프 라인을 구축하기 위해 많은 것을 개선시킬 수 있는 계기가 되었다.

🦐 Body

Geo Location 함수를 사용하고 싶다면 https를 적용하세요.

2015년부터 크롬 개발자들이 HTTP의 보안문제에 대해 이슈
가 되면서 GeoLocation API 기능제한에 대한 논의가 이루어졌다.

당연하게도 이번 프로젝트에서 사용되는 기능중 하나가 Geo Loacation이였고 서비스 환경을 HTTPS로 변경해야했다.
정리하자면 Docker 배포환경을 구축하기 위해서는 다음과 같은 조건을 만족해야했다.

1. Jenkins - Docker 간에 소켓(Docker.sock) 을 적용하여 CD를 이룰 것
2. Nginx를 적용하여 LB(로드 밸런스)를 구축할 것
3. HTTPS 를 적용할 것

SSL 적용

SSL을 적용하기 위해 NginX에 무료 SSL을 적용할 수 있는 CertBot 이미지를 사용했으며 NginX - Certbot 간편하게
을 사용하면 편리하게 구축이 가능하다.

Docker-compose 를 구분한 이유는?

Jenkins 에서 Build check 후 Build가 수행되는데 실제 서비스가 운영된다는 가정하에
배포가 한달에 2번 이상은 수행 될 것이며, 때마다 Nginx와 CertBot를 ReBuild 하는 번거로움을 피하고 싶었다.

때문에 SpringBoot Compose와 NginX, CertBot를 Compose를 구분하여 Spring 은 Jenkins 컨테이너 내부에 배치하여 Docker.sock으로 DooD 구성을 했고
HostOS에는 NginX - CertBot Compose를 위치하여 자원을 공유할 수 있도록 구성했다.

SpringBoot Compose

version: '3.0'
services:
  evrent1:
    container_name: evrent1
    build: .
    ports:
      - 9090:9090
    environment:
      MYSQL_HOST: 
      MYSQL_USER: 
      MYSQL_PASSWORD: 
      MYSQL_PORT: 3306
    volumes:
      - .:/usr/src
    restart:
      always
    depends_on:
      - mysql

  evrent2:
    container_name: evrent2
    build: .
    ports:
      - 9091:9090
    environment:
      MYSQL_HOST:
      MYSQL_USER: 
      MYSQL_PASSWORD:
      MYSQL_PORT: 3306
    volumes:
      - .:/usr/src
    restart:
      always
    depends_on:
      - mysql

  mysql:
    container_name: mysql
    image: mysql
    environment:
      MYSQL_DATABASE:
      MYSQL_ROOT_PASSWORD:
    volumes:
      - "/var/lib/mysql:/docker-entrypoint-initdb.d"
    ports:
      - 3307:3306

application.properties

server.port=9090

spring.devtools.livereload.enabled=true
#jsp\uc124\uc815
spring.mvc.view.prefix=/WEB-INF/views/
spring.mvc.view.suffix=.jsp

spring.datasource.hikari.driver-class-name=com.mysql.cj.jdbc.Driver
spring.datasource.hikari.jdbc-url=jdbc:mysql://mysql:3306/rent_car?useUnicode=true&characterEncoding=utf8
spring.datasource.hikari.username=root
spring.datasource.hikari.password=Wotjd@487

spring.datasource.hikari.maximum-pool-size=10
spring.datasource.hikari.minimum-idle=5
spring.datasource.hikari.connection-timeout=5000

spring.servlet.multipart.max-request-size=10MB
spring.servlet.multipart.max-file-size=10MB
spring.autoconfigure.exclude=org.springframework.boot.autoconfigure.web.servlet.error.ErrorMvcAutoConfiguration

server.error.whitelabel.enabled=false
server.error.path=/error

여기서 잘 봐둬야하는것은 url의 형태가 IP 가 아닌 하니의 컨테이너 이름으로 있다는 점과 Port 번호가 3307이 아닌 3306이라는 점이다.

spring.datasource.hikari.jdbc-url=jdbc:mysql://mysql:3306/rent_car?useUnicode=true&characterEncoding=utf8

url의 형태 중IP가 아닌 컨테이너 이름인 것은 docker-compose 내부에 하나의 셋트처럼 이루어져있어 서로 공유가 가능해서가 아닐까 생각한다.

미해결 에러

NginX - CertBot 을 Compose 하면 다음과 같이 HTTPS가 적용되었지만 인증되지 않은 인증서가 사용되었다는 주의가 화면에 보여진다.

기능적으로 서비스 사용이 불가능 한것은 아니지만 깔끔한 결과가 보여지지 못해 아쉽다.

결국 해결하지는 못했지만 오버플로우 에서는 유료 SSL 사용을 권장하며 CertBot에 대한 다음과 같은 에러의 원인을 해결한 개발자는 없는 듯 하다.

upstream evrent {
        least_conn;
        server evrent1:9090;
        server evrent2:9091;
   }

    server {
        listen      80 default_server;
        server_name evrent.ml;

    location /.well-known/acme-challenge/ {
        allow all;
        root /var/www/certbot;
    }

    location / {
        return 301 https://$host$request_uri;
    }

    }

server {
    listen 443 ssl;
    server_name evrent.ml;
        server_tokens off;

    ssl_certificate /etc/letsencrypt/live/evrent.ml/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/evrent.ml/privkey.pem;

    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;



    location / {
                proxy_pass http://evrent;
                proxy_set_header   Host             $http_host;
                proxy_set_header   X-Real-IP        $remote_addr;
                proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;

                proxy_buffering off;
                proxy_buffer_size 16k;
                proxy_busy_buffers_size 24k;
                proxy_buffers 64 4k;
}
}

Conclusion

compose 스크립트를 이해하고 구성하며 현재 환경에서 스스로가 계획한 로드맵 구현에 성공하면서
2달전과 비교하면 이제는 Docker를 다루는 능력이 향상된걸 느낀다.

그럼에도 Volume을 다루는 것은 아직까지도 어려우며
실제 서비스는 더욱 복잡하며 서비스를 세분화하여 관리할 테니 기초를 다시 한번 공부하는 시간을 가지는 것도 좋을 듯하다.

Refference

• My Repository
• http 프로토콜 사용시 HTML5 Geolocation API 등 위치정보 사용제한에 대하여