꿀잠

https://docs.aws.amazon.com/ko_kr/serverless-application-model/latest/developerguide/install-docker.html

# 패키지 ㅈ최신화
sudo yum update -y

# 도커 설치 시작
sudo yum install -y docker

# Docker 서비스 시작
sudo service docker start

# ec2-user가 docker 명령어 실행할 수 있도록 그룹에 추가
# 추가 이후 로그아웃 이후 로그인 해야 docker 명령어 사용가능
sudo usermod -a -G docker ec2-user

# 확인
docker ps 

@Test 어노테이션의 패키지를 확인해주자

import org.junit.jupiter.api.Test; // jupiter package, JUnit 5

@SpringBootTest

import org.junit.Test; // JUnit 4

@SpringBootTest
@RunWith(SpringRunner.class)

org.junit.jupiter.api.Test 패키지는 JUnit 5 를 사용하며 해당 어노테이션을 쓰지 않아도 동작하지만
org.junit.Test 패키지는 JUnit 4 를 사용하며 @RunWith(SpringRunner.class) 가 필수이다.

사이드 프로젝트 중 @Test 어노테이션 만으로도 동작하는 것을 확인하고 새로운 테스트 클래스를 만든 후에
스프링 빈이 주입되지 않아 당황하였다.
스프링 버젼 자체를 최신으로 해서 RunWith 어노테이션이 필요하지 않아진줄 알았지만
Test 어노테이션의 패키지가 영향을 준다는 사실을 확인했다.

커서 이동

• ctrl + a : 커서 맨 앞으로 이동 (Ahead)
• ctrl + e : 커서 맨 뒤로 이동 (End)
• ctrl + f : 커서 한 글자 다음으로 이동 (Foward)
• ctrl + b: 커서 한 글자 이전으로 이동 (Backword)
• alt + f : 커서 단어 하나 다음으로 이동 (Foward)
• alt + b : 커서 단어 하나 이전으로 이동 (Backword)
• ctrl + l : 화면 지우고 커서 화면 최상단 이동(cLear)

텍스트 편집

• ctrl + d : 커서 위치 글자 지우기 (Delete)
• ctrl + t : 커서 앞 글자와 위치 바꾸기 (Transmute)
• alt + t : 커서 위치 앞 단어 위치 바꾸기 (Transmute)
• alt + l : 커서 위치 있는 글자부터 그 단어 끝까지 소문자로 변경 (Lower)
• alt + u : 커서 위치 있는 글자부터 그 단어 끝까지 대문자로 변경 (Upper)

잘라내기 / 붙이기

• ctrl + k : 커서 줄 끝까지 잘라내기
• ctrl + u : 커서 그 줄 처음까지 잘라내기
• alt + d : 커서 단어 끝 부분까지 잘라내기
• alt + backspace : 커서 단어 앞 부분까지 잘라내기
• ctrl + y : 잘라낸 명령어 붙이기

docker-compose

# 전체 컨테이너 정지
docker-compose down

# 전체 컨테이너 실행
docker-compose up -d

# 특정 컨테이너 재실행 
docker-compose restart ${service-name}

docker hub

# 도커 허브에 로그인
docker login

# 도커 허브에 로그아웃
docker logout

# docker hub 에 올리기(push)
docker push ${repository}

docker

# 실행중인 도커 컨테이너 정보
docker ps 

# 이미지 목록보기
docker images

# 실행중인 도커 컨테이너 멈추기 ${name}은 ps 에서 확인가능
docker stop ${name}

# 현재 경로 도커 이미지 빌드(완료시 image id 획득)
docker build .
    # 이미지는 name:tag 로 식별자 부여
    # -t ${name}:${tag}

# 이미지 REPOSITORY(name), TAG 재설정
docker tag ${old-name}:${old-tag} ${name}:${tag}

# 컨테이너 생성 및 시작
docker run -p ${local-port}:${container-port} ${image-id}
    # -d : detached mode
    # -it 
        # -i : interactive(컨테이너 내부로 입력 가능하게 함)
        # -t : tty (터미널 생성)
    # -rm : 컨테이너 종료시 자동 제거
    # --name ${custom-continaer-name}: 원하는 컨테이너 이름 식별자 부여

# 컨테이너 백그라운드 시작
docker start ${container-id}
    # -a : attached mode

# 특정 컨테이너 내부 명령어 실행
docker exec ${container-name} ${command}

# 컨테이너 제거
docker rm ${...container-name}

# 이미지 제거 (컨테이너에서 사용되지 않는 것만 삭제 가능)
docker rmi ${...image-id}

# 사용되지 않는 이미지 전부 제거
docker image prune

# 로그 보기
docker logs
    # -f : follow mode

이전글 - 개발을 위해 Local, Dev Server WAS 환경 분리하기 1 - Intellij 환경 변수 이용하기 :: 꿀잠 (tistory.com)

WAS 환경을 분리하기 위해 axios 의 base url 을 분리하였고, 문제는 해결되어진 것으로 보았다. 그러나 그 이후 더 큰 문제가 발생하였다. 개발 WAS 에서 Session ID 가 요청마다 새로 생기는 문제였다. 우리의 로그인 방식이 세션 방식이었기에 이 문제는 크게 작용하였다.

로컬 WAS 환경에선 문제 없었으나 개발 WAS 에선 로그인 이후에 바로 다음 요청시 세션이 초기화 되어 로그인 인증을 할 수 없는 것이었다.

이것은 CSRF 방지를 위한 브라우저의 보안 정책 때문이었다. 세션 ID를 담은 쿠키를 보내려면 적절한 SameSite 정책이 포함되어야 하는 것이었다. Dev WAS 와 Local WEB으로 분리된 프로젝트 환경이기에 기본적으로 같은 사이트(SameSite)가 아닌 상황이었고, 서버는 SameSite 가 아닌 WEB 프로젝트의 쿠키를 폐기하고 새로 생성하였던 것이다.

아래와 같이 Spring Boot 의 CookieSerializer Bean을 새로 등록하는 방식으로 SameSite 정책을 None으로 변경해주었다.

@Bean
public CookieSerializer cookieSerializer() throws MalformedURLException {
    DefaultCookieSerializer serializer = new DefaultCookieSerializer();
    serializer.setSameSite("None");
    serializer.setUseSecureCookie(true); // None 일 경우 필수
    return serializer;
}

위와 같이 None 설정을 하여 진행하였지만 이후에 추가적인 문제가 생겼다. 바로 Secure 옵션을 반드시 주어야 한다는 점이다. 프로젝트에 HTTPS를 적용하여야 했다. Local 환경에 SSL 인증서를 설치하는 방법도 있지만 개발 환경에서 serve 명령어를 변경하여 간단히 해결하는 방법도 있다. package.json 에서 npm run serve 명령어를 아래와 같이 옵션을 주는 형태로 해결하였다.

 "serve": "vue-cli-service serve --https true",
 "serve-local": "vue-cli-service serve",

Dev Server WAS 환경을 바라 볼 때는 npm run serve 명령어를 사용하고, Local WAS 를 바라볼 때는 npm run serve-local를 사용하면 된다. Local 에서는 SameSite 인 상황이기에 쿠키의 새로운 생성을 걱정하지 않아도 되었기 때문이다.

분리 방법을 요약 하자면 아래와 같다.

1. 환경 변수를 이용한 axios base url 분리
2. Local Web -> Server Was 환경에서 Session 이 초기화 되면 안되는 환경일 경우 SameSite None, SecureCookie 설정
3. Local Web Https 적용(로컬 SSL 인증서 설치 또는 실행 명령어로 해결)

이로써 로컬 및 서버 WAS 인지에 따른 개발환경 분리를 완료할 수 있었다.

추가내용

CookieSerializer Bean 을 새로 등록하는 방법 외에도 방법이 있어 변경하여 적용후 남긴다.

개발 환경에서만 필요한 옵션이었기에 개발서버 기준application.properties 로 분리하였다.

server.servlet.session.cookie.same-site=none
server.servlet.session.cookie.secure=true

오늘은 개발시 프론트엔드(WEB) 프로젝트와 백엔드(WAS) 프로젝트로 분리되어 있을 시 LOCAL WAS 또는 배포되어진 WAS로 환경을 분리한 경험을 기록하고자 한다. 

현재 진행중인 프로젝트에서 HTML, CSS에 관한 부분을 타 회사 팀에서 맡게 되어 환경을 분리해야 하는 상황이 생겼다. 퍼블리싱을 담당한 회사는 우리 회사에서 만들고 있는 SpringBoot 프로젝트 환경이 없다 보니 이에 대한 부분을 제공해야 했기 때문이다. 퍼블리싱 이외의 javascript 관련 코드도 우리 팀이 맡은 상황이다 보니 ajax 코드가 추가될 시 퍼블리셔 업체에서 동작을 확인할 수 있도록 해주어야 했다. 

우리 팀은 WEB과 WAS 모두 개발하기 때문에 WAS 환경을 LOCAL 에서 실행하며 테스트 해야했고, 퍼블리셔를 위한 서버 WAS를 배포해주어야 했다. 이때 두 환경의 axios base url을 분리하여 이 부분을 해결하였다.

우리팀: Local Vuejs 개발 -> Local Was
퍼블리셔: Local Vuejs 개발 -> Dev Server Was

이러한 환경 분리를 위해 환경 변수를 이용하였으며 인텔리 제이에서 npm 실행 환경을 설정할 시 환경 변수를 주어 구분하였다. Edit congirutaion -> Environment 에서 간단히 가능하였다. 처음에 환경 변수를 설정하였는데도 불구하고 값이 제대로 읽혀지지 않아 이유를 찾아보니 명명법을 지켜야 제대로 읽을 수 있었다. 
Vue의 경우 "VUE_APP_" 이란 접두사를 붙여주어야 했다. React 의 경우 REACT_APP_ 이란 접두사를 붙여주어야 한다고 한다.

이를 통하여 axios 의 base url 을 분리하였고, 문제는 해결되어진 것으로 보았다. 그러나 그 이후 더 큰 문제가 발생하였다. 개발 WAS 에서 Session ID 가 요청마다 새로 생기는 문제였다. 우리의 로그인 방식이 세션 방식이었기에 이 문제는 크게 작용하였다. 

이것에 대한 내용은 다음 링크에 이어 쓰도록 하겠다.

다음글 - 개발을 위해 Local, Dev Server WAS 환경 분리하기 2 - SameSite란 :: 꿀잠 (tistory.com)