ctrl + alt + v : 객체 생성시 자동으로 변수 생성

ctrl + shift + enter : Code Completion -> Complete Current Statement

ctrl + shift + F10 : Run this class???

ctrl + alt + 왼쪽 화살표 : Navigate -> Back

alt + Insert :

 

ctrl + shift + T : 메서드에서 단축키를 누르면 Testcase 생성

shift + F6 : 변수명 바꾸기???

shift + F6 : 동시 수정???

 

ctrl + w : extended 영역 설정 ( 커서가 있는 단어 영역설정)  --> 누를 수록 해당하는 영역 확장

 

1. Token 이란?

토큰은 사용자의 신원을 확인하는 프로세스를 수행하거나 

사용자에게 작업 수행 권한을 부여하는 데 

충분한 정보가 포함된 데이터 조각입니다.

Tokens are pieces of data with just enough information
 to carry out the process of determining a user's identity,

  or authorizing a user to perform an action.

 

2. 사용자 인증

사용자 인증은 시스템이나 애플리케이션에 접근하려는 사용자를 확인하는 과정

 

인증은 여러 관점에서 분류를 할 수 있다. 

그 중에서 인증 상태를 관리하는 방식으로 나누면 크게 세션 기반토큰 기반으로 나뉜다.

어떤 방식으로 사용자 인증을 유지하고, 관리하는지에 따라 다양한 전략이 존재한다.

 

1) 인증 상태 관리 방식에 따른 분류

상태 기반 인증 ( Stateful Authentication )

서버가 사용자의 로그인 상태(Session) 를 유지하는 방식, 서버에 로그인 정보를 저장

Session 기반 인증이 대표적

서버가 로그인 상태를 저장하고 관리 => 관리 주체 : 서버

서버가 세션 ID 를 생성해서 클라이언트에게 주면 클라이언트는 세션 ID (일반적으로 쿠키)를 사용하여 인증 요청

문제 : 서버 확장성 문제, CORS 이슈,  서버 다운되면 모든 서비스 접속 불가, scale out시 서버끼리 데이터 불일치 가

 

무상태 기반 인증 ( Stateless Authentication )

서버가 로그인 상태를 유지하지 않으며,  => 로그인 정보를 저장하지 않음(Session을 기억하지 않음)

클라이언트가 인증 정보를 직접 보관하고 전달하는 방식

토큰 기반 인증이 대표적

서버에 사용자 로그인 정보를 저장하지 않고, 매 요청마다 토큰을 검증하여 사용자 인증

쿠키 대신 HTTP 헤더를 사용하여 CORS 문제 없음

문제 : 토큰 탈취 시 보안 문제, 토큰 무효화 어려움(로그아웃 후에도 토큰 살아있음, 강제 로그아웃하려면 블랙리스트 관리필요)

대표사용 : 모바일 앱 인증(OAuth2.0), MSA 환경

 

2) 인증 유지 방식에 따른 분류

세션 쿠키 ( Session Cookie )

클라이언트의 쿠키에 서버가 생성한 세션 ID를 저장하여 인증을 유지하는 방식

 

로컬 저장소 ( Local Storage )

클라이언트가 브라우저의 로컬 스토리지 (Local Storage ) 나 세션 스토리지 ( Session Storage ) 에 토큰을 저장하여 인증을 유지

확장성 높음

CORS 문제 없음 ( 헤더에 토큰을 넣어 요청 )

문제 : XSS 공격에 취약 ( 스크립트 공격으로 토큰을 탈취할 수 있음 ), 로그아웃 시 스토리지에서 직접 삭제해야하는 관리 필요

 

HTTP Only 쿠키 ( Secure Cookie )

HttpOnly 속성이 적용된 쿠키에 토큰을 저장하여 인증 유지

HttpOnly 속성이 있으면 JavaScript에서 접근이 불가하여 XSS 공격 방어 가능

문제 : CORS 설정 필요, 

 

3) 인증 연장 방식 (Token Refresh Strategy)

엑세스 토큰 + 리프레시 토큰 ( Access Token + Refresh Token )

엑세스 토큰 : 사용자가 서비스에 접근할 수 있는 사용자에 대한 정보를 담고 있음

리프레시 토큰 : 그 자체로는 별다른 정보를 담고 있지 않음.
    엑세스 토큰이 만료되었을 경우 서버에서 이를 확인하고 새로운 엑세스 토큰을 발급해주는 역할

짧은 수명의 엑세스 토큰과 긴 수명의 리프레시 토큰을 사용하여 인증을 지속

로그인 유지 기능

리프레시 토큰은 보안상 쿠키(HttpOnly)나 DB에 저장

문제점 : 리프레시 토큰 보관 주의

사용 예시 : OAuth 2.0 기반 인증, JWT 기반 서비스

 

 

3. 토큰 기반 인증

1) Access Token ( Token 1개 사용 ) - JWT로 사용

  • JWT( 2025.03.04 - [기타] - JWT 이론 정리 )는 Stateless => 서버에서 토큰의 상태를 제어할 수 없다.
  • 한계 : 외부 공격자가 토큰을 탈취하면 토큰이 만료될 때까지 속수무책이다. => 외부 접속인지 확인할 수 없다.

2) Access Token + Refresh Token ( Token 2개 사용 )

  • 리프레시 토큰은 그 자체로는 사용자 정보를 담고 있지 않아서 꼭 JWT 토큰을 사용하지 않아도 된다. JWT를 사용하지 않을 경우 저장하는 위치에 expiration값을 추가하면 된다.
  • 리프레시 토큰은 서버의 DB에 저장하기도 한다 => stateleful 해진다. (사용자 인증 정보가 없다고 생각해서 처음에는 인증에 직접적인 관계가 아니어서 stateless이나 stateful한지 여부와 무관하다고 생각했다.)
  • 엑세스 토큰의 유효시간을 짧게 설정할 수 있고 리프레시 토큰에 사용자의 정보를 가지고 있지 않아서 상대적으로 안전하다. 또한 더 다양한 방법으로 부족한 부분을 해결할 수 있다.

 

 

4. 구현 ( Access Token + Refresh Token )

'기타' 카테고리의 다른 글

JWT 이론 정리  (0) 2025.03.04

부트캠프 기간 동안 JWT에 대해 정확하게 알지 못하고 사용했다.

대충 session 대신에 토큰 기반으로 사용하고 클라이언트에 정보를 저장한다는 정도만 알고 있었다.

이렇게 사용하면 보안에 취약해보이는데 안전하게 사용(?)하는 곳이 많아서 급한대로 사용했다.

그러다가 로그인 파트를 정리하려고 하는데 그때 이해가 되지 않았던 부분들을 해결해야 할 것 같아서 정리한다.

이해가 되지 않았던 부분은 Access token과 Refresh token을 사용하는 방법이었다. 

이때 token은 모두 클라이언트에 저장되는 줄로 잘못 알고 있어서 생겼던 문제였다.

token을 2개를 쓴다고 해서 클라이언트에만 저장을 하는데 이게 왜 안전하지?라는 의문을 가졌다.

그런데 refresh token이 JWT로 구성된다는 오해와 서버에 저장되지 않는다는 부분에서의 문제였다.

아무튼 이해가 되지 않으니 좀 알고 넘어가는 것이 좋을 것 같아서 정리를 하게 됐다.

그러다가 session 방식과의 결합 아닌가 하는 의문도 생겼고 그 부분은 access token, refresh token 정리할 때 추가할 예정이다.

 

1. JWT 란?

JWT(JSON Web Token)은 웹표준(RFC7519)으로서 두 개체에서 JSON 객체를 사용 정보를 안전성 있게 전달하는 방식이다.

  • 특징
    • JWT는 JSON객체를 사용하여 가볍다.
    • JWT는 필요한 모든 정보를 자체적으로 지니고 있다.(self-contained, 자가 수용적)
    • 데이터 하나의 블럭이므로 쉽게 전달될 수 있다.

 

2. JWT 사용하기 ( 자세한 사용법 X )

1) Java JWT Github (github에 들어가면 사용법이 있습니다.)

https://github.com/jwtk/jjwt?tab=readme-ov-file

 

GitHub - jwtk/jjwt: Java JWT: JSON Web Token for Java and Android

Java JWT: JSON Web Token for Java and Android. Contribute to jwtk/jjwt development by creating an account on GitHub.

github.com

 

2) JWT Maven Central 저장소

https://mvnrepository.com/artifact/io.jsonwebtoken/jjwt-api

 

Central 탭의 Version을 누르면 Gradle dependency를 찾을 수 있음

 

3) Example

// 버전마다 사용하는 메서드가 다르므로 주의해야 함


// JWT 생성
private final SecretKey SECRET_KEY = Keys.hmacShaKeyFor("a-string-secret-at-least-256-bits-long");

public String generateJWT(String userRole) {

	// 버전 0.12.6
	return Jwts.builder()
        .claim(KEY_USER_ROLE, userRole)	// private claim
        .issuer("auth")		// registered claim
        .signWith(SECRET_KEY)
        .compact();
        
	// 버전 0.11.5
	//return Jwts.builder()
    //    .claim(KEY_USER_ROLE, userRole)	// private claim
    //    .setIssuer("auth")		// registered claim
    //    .signWith(SECRET_KEY)
    //    .compact();
}

 

// 버전마다 사용하는 메서드가 다르므로 주의해야 함


// JWT 검증
private final SecretKey SECRET_KEY = Keys.hmacShaKeyFor("a-string-secret-at-least-256-bits-long");

public boolean validateToken(String token) {

    // 버전 0.12.6
    Claims payload = Jwts.parser()
    			.verifyWith(SECRET_KEY)
    			.build()
    			.parseSignedClaims(token)
    			.getPayload();
    //byte[] content = Jwts.parser()
    //				.verifyWith(SECRET_KEY)
    //            .build()
    //            .parseSignedContent(token)
    //            .getPayload();
    // String payload = new String(content, StandardCharsets.UITF_8));
    
    
    // 버전 0.11.5
    //Claims payload = Jwts.parserBuilder()
    //            .setSigningKey(SECRET_KEY)
    //            .build()
    //            .parseClaimsJws(token)
    //            .getBody();
    
    
    // registered claim 중 issuer
	String issuer = payload.getIssuer();
    
    // private claim
    String userRole = payload.get(USER_ROLE, String.class);
    
    // ...
}

 

 

3. JWT 구성

'.(온점)'을 구분자로 3가지의 문자열로 구성

(header부) . (payload부) . (signature부)

 

1) Header 부

  • 2가지 정보(타입, 알고리즘)를 지님
    • 타입 : 토큰 타입을 지정. (JWT)
    • 알고리즘 : 해싱 알고리즘을 지정 ( HS256(HMAC SHA256) , RSA )
          Signature 생성시 사용
  • 해당 정보들을 인코딩(base64)을 하여 사용
# 헤더 구성
{"typ":"JWT","alg":"HS256"}

# base64 인코딩값
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9

2) Payload 부

  • 토큰에 담을 정보가 들어 있음 / Claim들의 집합
  • Claim : 담는 정보의 한 '조각'
  • Cliam의 종류
    • registered claim : 예약된 클레임
      jwts 클레임 메서드 ( 0.12.6 버전 기준)
      - issuer 
      - subject
      - audience
      - expiration
      - notBefore
      - issuedAt
      - id
      메서드로 JWT에 설정되는 값들은 각각 iss, sub, aud, exp, nbf, iat, jti 이다.
    • public claim
      충돌을 방지하기 위해 claim 이름을 URI형식으로
    • private claim
      양측 간에 협의해서 사용하는 claim 이름
# payload 내용
{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true,
  "iat": 1516239022
}

# base64 인코딩
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImlhdCI6MTUxNjIzOTAyMn0

※ base64로 인코딩 시, 공백/엔터들이 사라짐
  인코딩 문자열에 '=' 문자가 한두개 붙을 때가 있는데 이 문자를 base64 인코딩 padding문자라고 부름
  이 부분은 제거해도 디코딩할 때 전혀 문제가 되지 않음( 비트변환하면서 끝에 길이를 맞추면서 빈공간을 =으로 채워서 아무 의미 없음 ) - https://en.wikipedia.org/wiki/Base64#Examples
  URL 파라미터로 전달될 때 문제가 되므로 삭제해야 함

 

3) Signature 부

  • 헤더의 인코딩값과 정보의 인코딩값을 합친후 주어진 비밀키로 해쉬 함수를 사용하여 생성
    그후 base64형태로 인코딩하여 사용
# header와 payload를 . 으로 결합
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImlhdCI6MTUxNjIzOTAyMn0

# 결합한 값을 hs256으로 해싱함
# 이때 사용한 secret key == a-string-secret-at-least-256-bits-long
# 그후 base64 인코딩 부분
KMUFsIDTnFmyG3nMiGM6H9FNFUROf3wh7SmqJp-QV30

 

 

4) 결합한 JWT

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImlhdCI6MTUxNjIzOTAyMn0.KMUFsIDTnFmyG3nMiGM6H9FNFUROf3wh7SmqJp-QV30

 

 

 

 

※ JWT 인코더/디코더 사이트

https://jwt.io/

 

JSON Web Tokens - jwt.io

JSON Web Token (JWT) is a compact URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is digitally signed using JSON Web Signature (JWS).

jwt.io

 

 

 

참고 사이트 : https://velopert.com/2389

# This workflow will build and push a new container image to Amazon ECR,
# and then will deploy a new task definition to Amazon ECS, when there is a push to the "dev" branch.
#
# To use this workflow, you will need to complete the following set-up steps:
#
# 1. Create an ECR repository to store your images.
#    For example: `aws ecr create-repository --repository-name my-ecr-repo --region us-east-2`.
#    Replace the value of the `ECR_REPOSITORY` environment variable in the workflow below with your repository's name.
#    Replace the value of the `AWS_REGION` environment variable in the workflow below with your repository's region.
#
# 2. Create an ECS task definition, an ECS cluster, and an ECS service.
#    For example, follow the Getting Started guide on the ECS console:
#      https://us-east-2.console.aws.amazon.com/ecs/home?region=us-east-2#/firstRun
#    Replace the value of the `ECS_SERVICE` environment variable in the workflow below with the name you set for the Amazon ECS service.
#    Replace the value of the `ECS_CLUSTER` environment variable in the workflow below with the name you set for the cluster.
#
# 3. Store your ECS task definition as a JSON file in your repository.
#    The format should follow the output of `aws ecs register-task-definition --generate-cli-skeleton`.
#    Replace the value of the `ECS_TASK_DEFINITION` environment variable in the workflow below with the path to the JSON file.
#    Replace the value of the `CONTAINER_NAME` environment variable in the workflow below with the name of the container
#    in the `containerDefinitions` section of the task definition.
#
# 4. Store an IAM user access key in GitHub Actions secrets named `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY`.
#    See the documentation for each action used below for the recommended IAM policies for this IAM user,
#    and best practices on handling the access key credentials.

name: Deploy to Amazon ECS

on:
  push:
    branches: [ "dev" ]  # dev 브랜치로 push가 될 때(PR이 완료될 때)

env:
  AWS_REGION: ap-northeast-2                   # set this to your preferred AWS region, e.g. us-west-1


permissions:
  contents: read

jobs:
  build:
    name: Build Jar
    runs-on: ubuntu-latest

    steps:
    - name: Checkout
      uses: actions/checkout@v4		# 기존 정의되어 있는 actions를 사용

    - name: Set up JDK 17
      uses: actions/setup-java@v3
      with:
        java-version: '17'
        distribution: 'temurin'

    - name: Setup Gradle
      uses: gradle/actions/setup-gradle@af1da67850ed9a4cedd57bfd976089dd991e2582 # v4.0.0

  deploy:
    needs: build
    name: Deploy
    runs-on: ubuntu-latest
    environment: production

    steps:
    - name: Checkout
      uses: actions/checkout@v4

    - name: Configure AWS credentials
      uses: aws-actions/configure-aws-credentials@v1
      with:
        aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
        aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        aws-region: ${{ env.AWS_REGION }}

    - name: Login to Amazon ECR
      id: login-ecr
      uses: aws-actions/amazon-ecr-login@v1




    - name: Build dock-compose.yml
      run: docker compose build			# docker compose로 build하여 image 생성



    - name: Build, tag, and push image to Amazon ECR
      id: eureka-server-image
      env:
        ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}	# 이전 step 중 id가 login-ecr인 step의 결과(outputs) 중 registry를 사용
        IMAGE_TAG: ${{ github.sha }}
      run: |
        docker tag docker.io/library/eureka-server:latest ${{ env.ECR_REGISTRY }}/hobbing/eureka-server:${{ env.IMAGE_TAG }}
        docker push ${{ env.ECR_REGISTRY }}/hobbing/eureka-server:${{ env.IMAGE_TAG }}
        echo "image=${{ env.ECR_REGISTRY }}/hobbing/eureka-server:${{ env.IMAGE_TAG }}" >> $GITHUB_OUTPUT
    - name: Build, tag, and push image to Amazon ECR
      id: proxy-gateway-image
      env:
        ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}
        IMAGE_TAG: ${{ github.sha }}
      run: |
        docker tag docker.io/library/proxy-gateway:latest ${{ env.ECR_REGISTRY }}/hobbing/proxy-gateway:${{ env.IMAGE_TAG }}
        docker push ${{ env.ECR_REGISTRY }}/hobbing/proxy-gateway:${{ env.IMAGE_TAG }}
        echo "image=${{ env.ECR_REGISTRY }}/hobbing/proxy-gateway:${{ env.IMAGE_TAG }}" >> $GITHUB_OUTPUT   # image 변수를 $GITHUB_OUTPUT으로 추가
#    - name: Build, tag, and push image to Amazon ECR
#      id: gateway-image
#      env:
#        ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}
#        IMAGE_TAG: ${{ github.sha }}
#      run: |
#        docker tag docker.io/library/gateway:latest ${{ env.ECR_REGISTRY }}/hobbing/gateway:${{ env.IMAGE_TAG }}
#        docker push ${{ env.ECR_REGISTRY }}/hobbing/gateway:${{ env.IMAGE_TAG }}
#        echo "image=${{ env.ECR_REGISTRY }}/hobbing/gateway:${{ env.IMAGE_TAG }}" >> $GITHUB_OUTPUT
#    - name: Build, tag, and push image to Amazon ECR
#      id: user-image
#      env:
#        ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}
#        IMAGE_TAG: ${{ github.sha }}
#      run: |
#        docker tag docker.io/library/user:latest ${{ env.ECR_REGISTRY }}/hobbing/user:${{ env.IMAGE_TAG }}
#        docker push ${{ env.ECR_REGISTRY }}/hobbing/user:${{ env.IMAGE_TAG }}
#        echo "image=${{ env.ECR_REGISTRY }}/hobbing/user:${{ env.IMAGE_TAG }}" >> $GITHUB_OUTPUT
#    - name: Build, tag, and push image to Amazon ECR
#      id: coupon-image
#      env:
#        ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}
#        IMAGE_TAG: ${{ github.sha }}
#      run: |
#        docker tag docker.io/library/coupon:latest ${{ env.ECR_REGISTRY }}/hobbing/coupon:${{ env.IMAGE_TAG }}
#        docker push ${{ env.ECR_REGISTRY }}/hobbing/coupon:${{ env.IMAGE_TAG }}
#        echo "image=${{ env.ECR_REGISTRY }}/hobbing/coupon:${{ env.IMAGE_TAG }}" >> $GITHUB_OUTPUT
#    - name: Build, tag, and push image to Amazon ECR
#      id: lecture-image
#      env:
#        ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}
#        IMAGE_TAG: ${{ github.sha }}
#      run: |
#        docker tag docker.io/library/lecture:latest ${{ env.ECR_REGISTRY }}/hobbing/lecture:${{ env.IMAGE_TAG }}
#        docker push ${{ env.ECR_REGISTRY }}/hobbing/lecture:${{ env.IMAGE_TAG }}
#        echo "image=${{ env.ECR_REGISTRY }}/hobbing/lecture:${{ env.IMAGE_TAG }}" >> $GITHUB_OUTPUT
#    - name: Build, tag, and push image to Amazon ECR
#      id: reservation-image
#      env:
#        ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}
#        IMAGE_TAG: ${{ github.sha }}
#      run: |
#        docker tag docker.io/library/reservation-pay:latest ${{ env.ECR_REGISTRY }}/hobbing/reservation:${{ env.IMAGE_TAG }}
#        docker push ${{ env.ECR_REGISTRY }}/hobbing/reservation:${{ env.IMAGE_TAG }}
#        echo "image=${{ env.ECR_REGISTRY }}/hobbing/reservation:${{ env.IMAGE_TAG }}" >> $GITHUB_OUTPUT


    - name: Fill in the new image ID in the Amazon ECS task definition
      id: eureka-server-task-def
      env:
        ECS_TASK_DEFINITION: .github/workflows/hobbing-eureka-server-task-revision1.json # set this to the path to your Amazon ECS task definition # file, e.g. .aws/task-definition.json
        CONTAINER_NAME: hobbing-eureka-server-container-01           # set this to the name of the container in the
      uses: aws-actions/amazon-ecs-render-task-definition@v1
      with:
        task-definition: ${{ env.ECS_TASK_DEFINITION }}
        container-name: ${{ env.CONTAINER_NAME }}
        image: ${{ steps.eureka-server-image.outputs.image }}
    - name: Fill in the new image ID in the Amazon ECS task definition
      id: proxy-gateway-task-def
      env:
        ECS_TASK_DEFINITION: .github/workflows/hobbing-proxy-gateway-task-revision1.json # set this to the path to your Amazon ECS task definition # file, e.g. .aws/task-definition.json
        CONTAINER_NAME: hobbing-proxy-server-container           # set this to the name of the container in the
      uses: aws-actions/amazon-ecs-render-task-definition@v1
      with:
        task-definition: ${{ env.ECS_TASK_DEFINITION }}
        container-name: ${{ env.CONTAINER_NAME }}
        image: ${{ steps.proxy-gateway-image.outputs.image }}
#    - name: Fill in the new image ID in the Amazon ECS task definition
#      id: gateway-task-def
#      env:
#        ECS_TASK_DEFINITION: .github/workflows/hobbing-gateway-task-revision1.json # set this to the path to your Amazon ECS task definition # file, e.g. .aws/task-definition.json
#        CONTAINER_NAME: hobbing-gateway-server-container           # set this to the name of the container in the
#      uses: aws-actions/amazon-ecs-render-task-definition@v1
#      with:
#        task-definition: ${{ env.ECS_TASK_DEFINITION }}
#        container-name: ${{ env.CONTAINER_NAME }}
#        image: ${{ steps.gateway-image.outputs.image }}
#    - name: Fill in the new image ID in the Amazon ECS task definition
#      id: user-redis-task-def
#      env:
#        ECS_TASK_DEFINITION: .github/workflows/hobbing-user-task-revision1.json # set this to the path to your Amazon ECS task definition # file, e.g. .aws/task-definition.json
#        CONTAINER_NAME: hobbing-user-redis-container           # set this to the name of the container in the
#      uses: aws-actions/amazon-ecs-render-task-definition@v1
#      with:
#        task-definition: ${{ env.ECS_TASK_DEFINITION }}
#        container-name: ${{ env.CONTAINER_NAME }}
#        image: ${{ steps.login-ecr.outputs.registry }}/hobbing/redis-images:latest
#    - name: Fill in the new image ID in the Amazon ECS task definition
#      id: user-task-def
#      env:
#        ECS_TASK_DEFINITION: .github/workflows/hobbing-user-task-revision1.json # set this to the path to your Amazon ECS task definition # file, e.g. .aws/task-definition.json
#        CONTAINER_NAME: hobbing-user-service-container           # set this to the name of the container in the
#      uses: aws-actions/amazon-ecs-render-task-definition@v1
#      with:
#        task-definition: ${{ env.ECS_TASK_DEFINITION }}
#        container-name: ${{ env.CONTAINER_NAME }}
#        image: ${{ steps.user-image.outputs.image }}
#    - name: Fill in the new image ID in the Amazon ECS task definition
#      id: coupon-task-def
#      env:
#        ECS_TASK_DEFINITION: .github/workflows/hobbing-coupon-task-revision1.json # set this to the path to your Amazon ECS task definition # file, e.g. .aws/task-definition.json
#        CONTAINER_NAME: hobbing-coupon-server-container          # set this to the name of the container in the
#      uses: aws-actions/amazon-ecs-render-task-definition@v1
#      with:
#        task-definition: ${{ env.ECS_TASK_DEFINITION }}
#        container-name: ${{ env.CONTAINER_NAME }}
#        image: ${{ steps.coupon-image.outputs.image }}
#    - name: Fill in the new image ID in the Amazon ECS task definition
#      id: lecture-task-def
#      env:
#        ECS_TASK_DEFINITION: .github/workflows/hobbing-lecture-task-revision1.json # set this to the path to your Amazon ECS task definition # file, e.g. .aws/task-definition.json
#        CONTAINER_NAME: hobbing-lecture-server-container-01          # set this to the name of the container in the
#      uses: aws-actions/amazon-ecs-render-task-definition@v1
#      with:
#        task-definition: ${{ env.ECS_TASK_DEFINITION }}
#        container-name: ${{ env.CONTAINER_NAME }}
#        image: ${{ steps.lecture-image.outputs.image }}
#    - name: Fill in the new image ID in the Amazon ECS task definition
#      id: reservation-task-def
#      env:
#        ECS_TASK_DEFINITION: .github/workflows/hobbing-reservation-task-revision1.json # set this to the path to your Amazon ECS task definition # file, e.g. .aws/task-definition.json
#        CONTAINER_NAME: hobbing-reservation-server-container          # set this to the name of the container in the
#      uses: aws-actions/amazon-ecs-render-task-definition@v1
#      with:
#        task-definition: ${{ env.ECS_TASK_DEFINITION }}
#        container-name: ${{ env.CONTAINER_NAME }}
#        image: ${{ steps.reservation-image.outputs.image }}




    - name: Deploy Amazon ECS task definition
      uses: aws-actions/amazon-ecs-deploy-task-definition@v1
      env:
        ECS_SERVICE: hobbing-eureka-service-03                # set this to your Amazon ECS service name
        ECS_CLUSTER: hobbing-cluster-01                 # set this to your Amazon ECS cluster name
      with:
        task-definition: ${{ steps.eureka-server-task-def.outputs.task-definition }}
        service: ${{ env.ECS_SERVICE }}
        cluster: ${{ env.ECS_CLUSTER }}
        wait-for-service-stability: false
    - name: Deploy Amazon ECS task definition
      uses: aws-actions/amazon-ecs-deploy-task-definition@v1
      env:
        ECS_SERVICE: hobbing-proxy-service-03                # set this to your Amazon ECS service name
        ECS_CLUSTER: hobbing-cluster-01                 # set this to your Amazon ECS cluster name
      with:
        task-definition: ${{ steps.proxy-gateway-task-def.outputs.task-definition }}
        service: ${{ env.ECS_SERVICE }}
        cluster: ${{ env.ECS_CLUSTER }}
        wait-for-service-stability: false
#    - name: Deploy Amazon ECS task definition
#      uses: aws-actions/amazon-ecs-deploy-task-definition@v1
#      env:
#        ECS_SERVICE: hobbing-gateway-service-04                # set this to your Amazon ECS service name
#        ECS_CLUSTER: hobbing-cluster-01                 # set this to your Amazon ECS cluster name
#      with:
#        task-definition: ${{ steps.gateway-task-def.outputs.task-definition }}
#        service: ${{ env.ECS_SERVICE }}
#        cluster: ${{ env.ECS_CLUSTER }}
#        wait-for-service-stability: false
#    - name: Deploy Amazon ECS task definition
#      uses: aws-actions/amazon-ecs-deploy-task-definition@v1
#      env:
#        ECS_SERVICE: hobbing-user-service-03                # set this to your Amazon ECS service name
#        ECS_CLUSTER: hobbing-cluster-01                 # set this to your Amazon ECS cluster name
#      with:
#        task-definition: ${{ steps.user-task-def.outputs.task-definition }}
#        service: ${{ env.ECS_SERVICE }}
#        cluster: ${{ env.ECS_CLUSTER }}
#        wait-for-service-stability: false
#    - name: Deploy Amazon ECS task definition
#      uses: aws-actions/amazon-ecs-deploy-task-definition@v1
#      env:
#        ECS_SERVICE: hobbing-coupon-service-04               # set this to your Amazon ECS service name
#        ECS_CLUSTER: hobbing-cluster-01                 # set this to your Amazon ECS cluster name
#      with:
#        task-definition: ${{ steps.coupon-task-def.outputs.task-definition }}
#        service: ${{ env.ECS_SERVICE }}
#        cluster: ${{ env.ECS_CLUSTER }}
#        wait-for-service-stability: false
#    - name: Deploy Amazon ECS task definition
#      uses: aws-actions/amazon-ecs-deploy-task-definition@v1
#      env:
#        ECS_SERVICE: hobbing-lecture-service-03               # set this to your Amazon ECS service name
#        ECS_CLUSTER: hobbing-cluster-01                 # set this to your Amazon ECS cluster name
#      with:
#        task-definition: ${{ steps.lecture-task-def.outputs.task-definition }}
#        service: ${{ env.ECS_SERVICE }}
#        cluster: ${{ env.ECS_CLUSTER }}
#        wait-for-service-stability: false
#    - name: Deploy Amazon ECS task definition
#      uses: aws-actions/amazon-ecs-deploy-task-definition@v1
#      env:
#        ECS_SERVICE: hobbing-reservation-service-03               # set this to your Amazon ECS service name
#        ECS_CLUSTER: hobbing-cluster-01                 # set this to your Amazon ECS cluster name
#      with:
#        task-definition: ${{ steps.reservation-task-def.outputs.task-definition }}
#        service: ${{ env.ECS_SERVICE }}
#        cluster: ${{ env.ECS_CLUSTER }}
#        wait-for-service-stability: false

1. 선택하는 기준

팀의 요구사항, 프로젝트 규모, 인프라 환경 등을 고려

  1) 사용 목적과 요구사항 

  • gitLab cicd : 원격 git repository를 gitLab으로 사용 중이라면 자연스럽게...
  • gitHub actions : 원격 git repository를 gitHub로 사용 중이라면 자연스럽게...
  • Jenkins : 독립적인 CICD 환경이 필요하거나 커스텀이 많다면

 

  2) 설정 및 유지보수 편의성

  • gitLab cicd : .gitlab-ci.yml 하나로 설정 가능
  • gitHub actions : ./github/workflows/ 하위의 .yml 파일로 워크플로우 작성, Marketplace에 다양한 액션 제공
  • Jenkins : 서버관리 필요, 지원 플러그인 많지만 설정과 유지보수가  상대적으로 복잡

 

  3) 실행 환경 및 비용

  • gitLab cicd : 제한적 무료
  • gitHub actions : 제한적 무료
  • Jenkins : 자체 서버 구축 필요, 클라우드 사용 시 비용 고려

 

  4) 확장성과 커스터마이징

  • Jenkins 가 상대적으로 많은 플러그인 제공
  • gitLab cicd, gitHub actions : gitLab과 gitHub의 연동이 가능한 이점으로 접근성이 좋고 점점 활성화되고 있음

 

  5) 선택

  • 원격 git repository를 사용한다면, 각각 gitHub actions, gitLab cicd로 자연스럽게 선택
  • on-premise 환경이나 커스텀에 초점을 맞춘다면, Jenkins를 선택

 

 

 

 

 

 

 

 

 

https://docs.github.com/ko/actions

 

GitHub Actions 설명서 - GitHub Docs

GitHub Actions를 사용하여 리포지토리에서 바로 소프트웨어 개발 워크플로를 자동화, 사용자 지정 및 실행합니다. CI/CD를 포함하여 원하는 작업을 수행하기 위한 작업을 검색, 생성 및 공유하고 완

docs.github.com

 

https://docs.gitlab.com/ci/

 

Get started with GitLab CI/CD | GitLab Docs

Get started with GitLab CI/CD Tier: Free, Premium, UltimateOffering: GitLab.com, GitLab Self-Managed, GitLab Dedicated CI/CD is a continuous method of software development, where you continuously build, test, deploy, and monitor iterative code changes. Thi

docs.gitlab.com

 

https://www.jenkins.io/doc/

 

Jenkins User Documentation

Jenkins – an open source automation server which enables developers around the world to reliably build, test, and deploy their software

www.jenkins.io

 

 

 

1. SSH KEY 등록

  1) ssh key 생성

ssh-key -t rsa

 

  2) 생성된 public ssh key 등록 

 - github ssh-key 등록 페이지

  • 해당 페이지에서 생성한 ssh-key 등록

 

 - gitlab ssh-key 등록 페이지

 

  • 해당 페이지에서 생성한 ssh-key 등록

 

 

1. 새로운 그룹명이 필요할 경우 생성

sudo groupadd [그룹명]   # 그룹명이라는 그룹을 생성

 

2. 그룹에 계정을 추가

sudo usermode -G [그룹명] [linux일반계정]   # 그룹에 linux일반계정을 추가시킴 / 기존 속한 그룹 삭제

sudo usermode -aG [그룹명] [linux일반계정]  # 그룹에 linux일반계정을 추가시킴 / 기존 속한 그룹 유지

 

3. 해당 그룹 재실행

newgrp [그룹명]    # 현재 터미널 세션에서 해당 그룹을 적용하여 즉시 적용
ssh-key -t rsa    # rsa방식의 ssh 키 private-key와 ssh public-key 쌍을 생성

+ Recent posts