HwangHub

보호되어 있는 글입니다.

사이드 프로젝트(송곳매)를 진행하던 중, 정적 페이지 호스팅을 위해 s3를 활용하였는데, 호스팅 이후에 no such key라는 이슈가 발생하였다. 문제 상황 문제를 재현해보면 다음과 같다. 나는 index.html을 요청하기 위해 루트 도메인 주소(www.songgotmae.com)를 호출하였는데, 아래와 같은 페이지가 뜨며 에러가 발생하였다. 문제 원인 기본적으로 S3는 파일을 key-value 형식으로 저장한다. 여기서 key는 파일 이름, 그리고 value는 파일 객체를 의미한다. 따라서 no such key라는 것은, 요청한 url에 해당하는 파일을 찾을 수 없다는 것을 의미한다. s3 호스팅 설정을 보면, main.html을 index 페이지로 제공할 수 있도록 설정해 두었는데, (당연하지만)..

오늘날 많은 IT 기업에서 쿠버네티스를 사용하고 있는데, 이들이 k8s(쿠버네티스)를 사용하는 이유를 단순히 "요즘은 서비스 구조로 대부분 MSA를 적용하니까" 보다 조금은 더 디테일한 이유를 간단하게 파악해보기 위해선 클라우드 컴퓨팅을 왜 사용하는지부터 알아야 합니다. 클라우드 컴퓨팅을 사용하는 이유 컴퓨터를 이용하여 서비스 환경을 구축하기 위해선 우리가 일상적으로 사용하는 컴퓨터(PC)와 비교하여 더 많은 연산량을 처리해야 했고, 제너럴하게 이용되는 PC와 달리 보다 목적에 최적화된 구조가 필요했습니다. 이를 위해 서버 컴퓨터라는 개념이 등장하게 되었습니다. 사실 크게 다르진 않고, CPU나 마더보드, 그리고 주변 장치(네트워크)로 이어지는 길이가 일반 컴퓨터에 비해 넓고 빠르며, 설계 목적이 '36..

과거 내 블로그 migration 지라 회원가입 슬랙 가입 깃허브 가입 지라 프로젝트 매니징 시작하기 지라에서 프로젝트 생성!!! 지라에서 프로젝트 생성하기 슬랙과 지라 연동 슬랙-지라 연동하기 슬랙에서 app -> "지라" 앱 설치 지라에서 슬랙 허용 및 slack integration 설정 슬랙에서 /jira connect -> project 연결 슬랙에 깃허브 연동 슬랙에서 app -> "github" 앱 설치 슬랙에 깃 계정 연동 /github subscribe owner/repo 지라와 github 연동 위 사진 중 app에서 github for jira (pick) 설치 및 연동 지라에서 깃허브 레포 연동 깃허브에서 슬랙/지라 연동 Settings->Applications에서 깃허브 앱 중에서..

항상 코드를 조금만 수정해도 반복해줘야 하는 배포 작업이 번거롭고 부담스러운 작업이라 느꼈다. 또한 여러 스크립트를 입력해야 하므로 보통 복붙을 하게 되는데, 만약 손으로 타이핑할 필요가 있을 때마다 오타 등의 휴먼 에러가 종종 발생하기도 했다. 따라서 이를 최소화하기 위해 배포 자동화에 관심을 갖게 되었고, 깃허브를 소스코드 보관 플랫폼으로 이용하고 있는 김에 젠킨스나 다른 툴 보다도 접근성도 좋고 무료인 깃허브 액션으로 먼저 해당 기술을 익혀보고자 했다. 다음 내용은 송곳매 프로젝트 진행 중에 발생한 이슈를 해결한 내용입니다. 배포 자동화 스크립트 전문을 우선 첨부한 뒤에, 차근차근 작성했던 것들을 설명해보고자 한다. 배포 자동화 스크립트 전문은 다음과 같다. name: stage-server-dep..

다음 내용은 송곳매 프로젝트 진행 중에 발생한 이슈를 해결한 내용입니다. ubuntu 환경의 ec2에 docker를 이용하여 배포를 하려고 docker를 나름대로 설치하고 docker ps를 수행했는데 다음과 같은 에러가 발생하였다. $ docker ps Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running? 알아보니 systemctl status docker 를 통해 체크해보면 대부분 아래와 같이 docker가 ec2 컴퓨터 내에서 실행되고 있지 않아서 그렇다고 한다. $ systemctl status docker docker.service - Docker Application Con..

도커는 오늘날 전 세계에서 개발자들이 가장 많이 사용하는 오픈소스 2위에 등극될 만큼 많이 활용되는 기술인데요. (1위는 git 입니다.) 이번 포스팅에서는 도커를 이용하여 AWS EC2 환경에 배포를 해보면서, 왜 다들 도커를 사용하는지 느껴보는 시간을 가져보겠습니다! 도커는 깔려있다고 가정합니다. 0. 실습 환경 윈도우 11 jdk 17 springboot intelliJ ultimate docker desktop EC2 : ubuntu 22.04 1. AWS EC2와 소스 코드 세팅하기 우선 배포할 코드와 서버 컴퓨터 역할을 해줄 EC2가 필요할 것입니다. 저의 경우에는 현재 진행하고 있는 프로젝트 코드를 배포하려고 하고 있으며, 서버 컴퓨터는 프리티어 EC2인 t2.micro를 이용할 것입니다. ..

우리가 single execution jar 파일을 빌드하고 단일 컨테이너만 실행하면 원하는 서비스를 모두 제공할 수 있는 거라면 좋겠지만, 서비스에 따라 레디스와 같은 이미지를 별도 컨테이너에 띄워야 하는 경우도 있고, 서비스가 커지기 시작하면 멀티 모듈을 적용하게 되므로 여러 어플리케이션을 동시에 각각 컨테이너에 올려야 하는 경우도 발생하게 됩니다. 이를 원활하게 컨트롤하기 위해 우리는 docker compose를 사용합니다. 도커 컴포즈란? 도커 컴포즈는 다중 컨테이너 도커 어플리케이션을 정의하고 실행하기 위한 도구입니다. docker compose를 이용하면 컨테이너 이름으로 다른 application.yml 파일에서 해당 컨테이너에 접근할 수 있습니다. 이는 redis 설정시 host 이름을 설..

도커파일을 보다보면 WORKDIR이란 게 있습니다. 이건 뭘까요? working directory란? 이미지 내부에서 어플리케이션 소스코드를 저장할 디렉토리를 의미합니다. 이를 설정하기 위해서는 도커파일에 WORKDIR 명령어를 이용하여 우리의 어플리케이션 소스코드 저장 디렉토리를 생성할 수 있습니다. WORKDIR /usr/src/app 그런데 왜 별도로 working directory를 지정해야 할까요? WORKDIR을 지정하지 않고 냅다 COPY만 해서 이미지를 생성할 경우, 만약 base image가 가지고 있던 파일과 내가 이미지로 빌드할 어플리케이션의 파일 이름이 겹친다면 베이스 이미지의 파일이 덮어쓰기를 당하게 됩니다. 또한 당연히 모든 파일이 이미지 내의 root 경로에 전부 때려박아지니 ..

앞서 docker build ./ 명령어를 이용하여 Dockerfile을 이미지로 생성해봤는데요. 이번에는 그 이미지를 실행해 보도록 하겠습니다. 실행시에 아웃풋을 보기 위해선 it 옵션을 활용해야 합니다. docker run -it 위와 같이 이미지 아이디로도 실행이 가능하지만, 우리는 이미지 아이디를 매번 기억하고 있기 어렵기 때문에 이미지 빌드를 할 때에도 이름을 설정해주곤 합니다. 따라서 아래와 같이 보통 실행합니다. 여기서 이미지 아이디를 이용하여 실행하려고 할 때에는 이미지 아이디를 한 글자도 빠짐없이 전부 기입하지 않고 일부만 해 주어도 도커가 인식만 가능하다면 자동으로 사용자의 의도에 맞는 이미지 아이디를 찾아서 실행시켜 줍니다. 그런데, 위 과정까지만 하면 분명 실행되는 것처럼 나오는데,..