version: '3'

services:
  keycloak:
    image: quay.io/keycloak/keycloak:latest
    restart: always
    container_name: keycloak
    environment:
      - KEYCLOAK_ADMIN=admin
      - KEYCLOAK_ADMIN_PASSWORD=admin
      - KC_DB=postgres
      - KC_DB_URL=jdbc:postgresql://postgres/keycloak
      - KC_DB_USERNAME=postgres
      - KC_DB_PASSWORD=postgres
      - KC_HOSTNAME=localhost
      - KC_DB_SCHEMA=public
    ports:
      - "8080:8080"
    command: start-dev
    depends_on:
      - postgres
    networks:
      - [network]

networks:
  [network]:
    external: true
반응형

'Docker > docker-compose' 카테고리의 다른 글

docker-compose로 postgresql 올리기  (0) 2023.12.06
docker-compose로 Swagger 올리기  (0) 2023.09.25
version: '3'

services:
  postgres:
    image: postgres:latest
    restart: always
    container_name: postgres
    ports:
      - "5432:5432"
    environment:
      POSTGRES_DB: postgres
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: postgres
    volumes:
      - ./volume/postgresql/:/var/lib/postgresql/data
      - ./sql:/docker-entrypoint-initdb.d
    networks:
      - [network]
      
networks:
  [network]:
    external: true
반응형

'Docker > docker-compose' 카테고리의 다른 글

docker-compose로 keycloak 올리기  (0) 2023.12.06
docker-compose로 Swagger 올리기  (0) 2023.09.25

기존 AWS CLI v1의 아마존 ECR 로그인 같은경우

$ $(aws ecr get-login --no-include-email --region ap-northeast-2)

 

이와 같은 방식으로 명령어를 실행하였으며 $()는  괄호 사이의 명령을 실행한 다음 그 결과 문자열을 다시 실행하는 쉘 문법이다. 따라서 $() 를 제거하고 실행하면 실제로 실행되는 명령어를 확인할 수 있으며 이때의 명령어는

$ aws ecr get-login --no-include-email --region ap-northeast-2
docker login -u AWS -p <Password> https://<ACCOUNT_ID>.dkr.ecr.ap-northeast-2.amazonaws.com

 

실제로 docker login 명령어가 실행되는 것을 확인할 수 있다. 명령어를 실행하는 시점에 AWS CLI가 임시 패스워드를 받아와 프라이빗 도커 레지스트리에 로그인을 수행한다.

 

변경된 AWS CLI v2의 아마존 ECR 로그인 방법(AWS CLI 버전에 따라 v1의 ECR 명령어가 실행 안됨)

$ aws ecr get-login-password --region region | docker login --username AWS --password-stdin aws_account_id.dkr.ecr.region.amazonaws.com

 

반응형

https를 통한 인터넷 접속은, 브라우저를 실행 중인 우리 컴퓨터가 해당 사이트의 서버와 암호화 통신을 하고 있다는 것을 의미하며 이렇게 https 를 이용한 인터넷 접속은 SSL을 이용한 것이라고 보면 된다. 즉, SSL 암호화 통신은 SSL(Secure Socket Layer) 또는 TLS(Transport Layer Security)라는 보안 프로토콜을 통해 클라이언트와 서버가 보안이 향상된 통신을 하는 것을 의미한다.  정리하자면

SSL과 TLS는 보안 계층이라는 독립적인 프로토콜 계층을 만들어, 위그림과 같이 Application 계층과 Transport 사이에 속하게 된다. 즉 https 는 SSL 또는 TLS 위에 http 프로토콜을 얹어 보안된 http 통신을 하는 프로토콜이다. 즉 SSL과 TLS는 http 뿐만 아니라 ftp, smtp와 같이 다른 프로토콜에 적용할 수 있다. 그리고 SSL과 TLS는 같은 의미의 단어이며 TLS가 SSl의 후속 버전이지만, SSL이 일반적으로 더 많이 사용되는 용어이다.

 

SSL 암호화 통신은 크게 세가지 핸드 쉐이크, 전송, 종료 데이터를 주고받기 위해 어떤 방법을 사용해야 하는지 서로의 상태를 파악하며 SSL은 80번 포트를 사용하는 http와 달리 443번 포트를 기본으로 사용하는 TCP기반의 프로토콜이다. TCP 기반이기 때문에 SSL 핸드쉐이크를 하기전에 TCP 3-way 핸드쉐이크 또한 수행하며 서로간 협상이 완료되면, SSL 세션이 생성되고 클라이언트와 서버는 원하는 데이터를 주고 받게 된다. 그리고 데이터 전송의 끝을 서로에게 알리며 세션을 종료한다. 

 

핸드쉐이크 단계에서 서로 어떤 것들을 협상하게 되는가.

 

- Client hello : 클라이언트가 서버에게 연락합니다. 브라우저 검색창에 도메인을 입력하는 것으로 보면 됩니다. 이때 클라이언트는 자신의 브라우저가 지원할 수 있는 암호화 방식(Cipher Suite)을 먼저 제시합니다. 그리고 랜덤 데이터를 생성하여 추가로 전송합니다. 

- Server hello : 서버가 클라이언트에게 연락합니다. 서버는 클라이언트가 제시한 암호화 방식 중 하나를 선정하여 알려줍니다. 또한, 서버 자신의 인증서를 전달합니다. 이 인증서에는 서버의 공개 키가 포함되어 있습니다. 클라이언트와 마찬가지로 서버 측에서 생성한 랜덤 데이터 또한 전달합니다.

- Client key exchange : 클라이언트는 미리 주고받은 자신과 서버의 랜덤 데이터를 참고하여 서버와 암호화 통신을 할 때 사용할 키를 생성한 후 서버에게 전달합니다. 이때 키는 서버로부터 받은 공개키로 암호화되어 보내집니다.

- Finished : 마지막으로 핸드셰이크 과정이 정상적으로 마무리되면, 클라이언트와 서버 모두 “finished” 메시지를 보냅니다. 그 후부턴 클라이언트가 생성한 키를 이용하여 암호화된 데이터를 주고받게 됩니다.

 

이러한 <b>오늘은 무료 SSL 인증서 "Let's Encrypt" 적용 방법</b> 에 대해서 알아보겠습니다. 무료 SSL과 유료 SSL의 차이에 대해 궁금할텐데 알고리즘 방식은 크게 차이가 없지만(무료같은 경우 sha256) 인증서 유효기간이 90일이기에 3개월에 한번씩 인증서를 갱신을 해야하며(자동 갱신 설정하면 자동으로 갱신이 되니 단점 x)

또 다른점은 멀티 도메인 지원이 안된다. 서브도메인이라고 할수 있는데 이러한 서브도메인을 위해 인증서를 또 받아야 한다.

 

// cerbot 설치
$ sudp apt install cerbot

// 도메인 등록
$ sudo certbot certonly --webroot -w .{웹루트 위치} -d {등록할 도메인 or 서브 도메인}
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Enter email address (used for urgent renewal and security notices)
 (Enter 'c' to cancel): {이메일 주소 등록}

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Please read the Terms of Service at
https://letsencrypt.org/documents/LE-SA-v1.3-September-21-2022.pdf. You must
agree in order to register with the ACME server. Do you agree?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Y)es/(N)o: y

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Would you be willing, once your first certificate is successfully issued, to
share your email address with the Electronic Frontier Foundation, a founding
partner of the Let's Encrypt project and the non-profit organization that
develops Certbot? We'd like to send you email about our work encrypting the web,
EFF news, campaigns, and ways to support digital freedom.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Y)es/(N)o: y
Account registered.
Requesting a certificate for {위에서 등록한 도메인 주소}

Certbot failed to authenticate some domains (authenticator: webroot). The Certificate Authority reported these problems:
  Domain: firstchart.mediview.kr
  Type:   unauthorized
  Detail: {Ip Address}: Invalid response from {위에서 등록할 도메인 주소}/.well-known/acme-challenge/sjxE1EUknc8W7I4LEiCSN-k1csmMEyEw8Jy9sVEFVug: 404

Hint: The Certificate Authority failed to download the temporary challenge files created by Certbot. Ensure that the listed domains serve their content from the provided --webroot-path/-w and that files created there can be downloaded from the internet.

// 등록된 Ip Address내의 /.well-known/acme-challenge/sjxE1EUknc8W7I4LEiCSN-k1csmMEyEw8Jy9sVEFVug
// 위의 파일이 없어서 생기는 오류

 

반응형

AWS CLI은(는)  AWS Command Line Interface의 약자로 명령줄 셸의 명령을 사용하여 AWS 서비스와 상호 작용할 수 있는 오픈 소스 도구이다. 공식문서에서 다음 링크와 같이 AWS CLI를 설치 안내하며 설치 후 아래와 같이 동작한다.

$ aws --version
aws-cli/2.13.33 Python/3.11.6 Linux/3.10.0-1160.102.1.el7.x86_64 exe/x86_64.centos.7 prompt/off

 

이렇게 AWS CLI 설치 후 AWS CLI에서 다양한 리소스를 다루기 위해서 자격 증명이 필요하다.

이 경우 CentOS 기준으로,  profile 및 기본설정 명령어는 아래와 같으며 

$ aws configure
AWS Acess Key Id: { aws_access_key_id }
AWS Secret Access Key: { aws_secret_access_key }
Default region name: ap-northeast-2
# AWS 자원에 대한 응답의 기본 포맷으로 text, table, yml 등이 있다.
Default output format: json

# 특정 profile 별 액세스 키 설정
$ aws configure --profile dev

# 아래 명령어로 현재 설정된 프로그램 액세스 키가 어느 계정에 소속된 것인지 조회할 수 있다
$ aws --region ap-northeast-2 iam get-user

# 프로파일 별 계정 정보 조회
$ aws --profile dev --region ap-northeast-2 iam get-user

 

아래에 위치한 경로 내에 설정한 profile 별 계정 정보를 확인 및 수정할 수 있다.

// /home/{user}/.aws
$ cat credentials 
[default]
aws_access_key_id = { aws_access_key_id }
aws_secret_access_key = { aws_secret_access_key }
[user-1]
aws_access_key_id = { aws_access_key_id }
aws_secret_access_key = { aws_secret_access_key }

 

 

반응형

'AWS > IAM & AWS CLI' 카테고리의 다른 글

AWS - IAM, User, UserGroup, Role, Policy에 대한 관계  (0) 2023.04.15

1. Spring Servlet 이란?

Dispatcher Servlet 을 설명하기 이전에 Dispatcher Servlet은 Servlet의 일종이기에 우선 Servlet에 대해 먼저 설명하고자 한다.

Servlet 이란 자바 언어를 기반으로 웹 애플리케이션 개발을 위한 플랫폼-독립적인 서버 사이드 컴포넌트로써, 다음과 같은 특징을 가진다.

 

1. 플랫폼 독립성 : 서블릿은 Java언어로 작성되므로, 어떤 플랫폼에서도 동작할 수 있으며, 즉 '한 번 작성, 어디서나 실행'의 장점을 제공. 

 

2. 웹 애플리케이션 개발 : 서블릿은 주로 동적인 웹 애필리케이션을 개발하는데 사용되며  이는 웹 요청을 처리하고 HTTP 응답을 생성하는데 특히 유용.

 

3. 스레드 기반 : 서블릿은 멀티스레드 환경에서 동작하며, 각 클라이언트 요청에 대해 새로운 스레드를 생성하거나 스레드 풀을 사용하여 요청을 동시에 처리할 수 있다.

 

4. 웹 컨테이너 : 서블릿은 웹 컨테이너 내에서 동작하며 웹 컨테이너는 서블릿의 생명주기 관리와 HTTP 요청 및 응답을 처리한다.

5. HTTP프로토콜 지원 : 서블릿은 HTTP 프로토콜을 기반으로 클라이언트와 상호작용한다. HTTP 요청 메서드 및 헤더를 처리하며, HTTP 응답을 생성한다.

 

6. 웹 애플리케이션 서비스 : 서블릿은 다양한 웹 애플리케이션 서비스를 제공할 수 있다. 예를 들어, 사용자 인증, 데이터베이스 연동, 등등이 있다.

 

7. 생명주기 관리 : 서블릿은 특정한 생명주기를 따르며 서블릿 컨테이너는 서블릿을 초기화하고, 요청을 처리하며 종료하는데 필요한 메서드를 호출한다.

 

결론적으로 서블릿은 JavaEE 스펙의 일부로, 웹 애플리케이션을 개발하고 웹서버에서 실행할 때 매우 유용한 기술이다.

 

2. Spring Dispatcher Sevlet이란?

Spring Dispatcher Servlet은 Spring Framework에서 중요한 역할을 하는 핵심 컴포넌트 중 하나로 Dispatcher Servlet은 웹 애플리케이션의 모든 HTTP 요청을 처리하고 요청을 적절한 핸들러로 라우팅하는 역할을 하며 다음과 같은 주요 특징을 지니고 있다.

 

1. Front Controller : Dispatcher Servlet은 웹 애플리케이션의 Front Controller로 동작한다. 모든 클라이언트의 HTTP 요청은 먼저 Dispatcher Sevlet에 의해 수신된다.

 

2. 요청 라우팅 : Dispatcher Sevlet은 URL 패턴을 기반으로 HTTP 요청을 적절한 컨트롤러로 라우팅한다. 이를 통해 요청을 처리할 컨트롤러를 선택하고 실행할 수 있다.

 

3. 뷰 렌더링 : Dispatcher Servlet은 컨트롤러에서 반환된 뷰를 선택하고 해당 뷰를 클라이언트에 렌더링한다. 이를 통해 웹 페이지를 동적으로 생성하고 반환할 수 있다.

 

4. Handler Mapping : Dispatcher Servelt은 라우팅을 위해 Handler Mapping이라고 불리는 구성 요소를 사용한다. Handler Mapping은 URL 패턴과 컨트롤러 사이의 매핑 정보를 제공한다.

 

5. View Resolver : DIspatcher Servlet은 뷰 렌더링을 위해 View Resolver를 사용하며 View Resolver는 컨트롤러에서 반환된 뷰 이름을 실제 뷰 객체로 해석하고 렌더링 한다.

 

6. 인터셉터 : Dispatcher Servlet은 인터셉터를 지원하여 요청 처리 전후에 특정 작업을 수행할 수 있게 한다. 예를 들어, 보안 체크, 로깅 트랜잭션 관리가 있다.

 

7. 에러처리 : Dispatcher Servlet은 요청 처리 중 발생하는 에러를 처리하고 오류 페이지로 리다이렉션 하거나 에러 메시지를 제공하는 역할을 한다.

 

3. DispatcherServlet 구조도(spring-webmvc:6.0.11)

 

 

DispatcherServlet은  

반응형

개발 서버에 도커 컨테이너로 swagger를 말아 올려 간단히 api 문서만 볼 수 있게 만들기로 하여 공식문서등을 참고하여 해결했다. 여러분들은 저와같은 실수를 하지 말라며 실제 실행 완료한 docker-compose 파일문을 남긴다.

version: '3.3'

services:
  swagger-ui:
    image: swaggerapi/swagger-ui:latest
    restart: always	
    container_name: swagger-ui
    environment:
      URLS: "[{url: 'doc/auth.json', name: 'AuthServer'}]"
    volumes:
      - /data/volume/swagger/:/usr/share/nginx/html/doc
    ports:
      - 9999:8080
    networks:
      - sample

networks:
  sample:
    external: true

 

 

 

 

https://stackoverflow.com/questions/56541964/providing-local-file-to-swagger-ui-through-docker

 

Providing local file to swagger ui through Docker

I have read on https://swagger.io/docs/open-source-tools/swagger-ui/usage/installation/ that it is possible to host a local file (swagger.json) on swagger ui through docker by writing docker run -...

stackoverflow.com

 

https://articles.wesionary.team/swagger-ui-on-docker-for-testing-rest-apis-5b3d5fcdee7

 

Swagger UI on docker for testing REST APIs

Testing REST APIs in software development is an important part of any development process. As so, it’s a very important role of the QA…

articles.wesionary.team

 

 

반응형

'Docker > docker-compose' 카테고리의 다른 글

docker-compose로 keycloak 올리기  (0) 2023.12.06
docker-compose로 postgresql 올리기  (0) 2023.12.06

Entity에 대해서 롬복 어노테이션인 @EequalsAndHashCode를 적용하게 되면 모든 인자값을 서로 비교하여 객체를 검사하기에

Id만 선택하여 @EquealsAndHashCode를 작성한다.

 

아래는 그와 관련된 간단한 예제 코드이다.

@Getter
@ToString
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@Table(indexes = {
        @Index(columnList = "title"),
        @Index(columnList = "hashtag"),
        @Index(columnList = "createdAt"),
        @Index(columnList = "createdBy")
})
@Entity
public class Article {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @Setter
    @Column(nullable = false)
    private String title;

    @Setter
    @Column(nullable = false, length = 1000)
    private String content;

    ...

	// AS-IS
    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
        Article article = (Article) o;
        return Objects.equals(id, article.id);
    }


	// TO-BE
    // 객체 타입이 object 타입인지 확인한 후(instanceof) object를 비교할 객체 타입으로 
    // casting 하는 과정이 필요했는데 자바버전 14 이후로 그 과정이 없어졌고, 
    // scope 안에 참조변수를 넣을 수 있게 되었고 이를 Pattern variable이라 한다.
    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (!(o instanceof Article article)) return false;
        return id != null && id.equals(article.id);
    }

    @Override
    public int hashCode() {
        return Objects.hash(id);
    }
}

더 자세한 내용은 밸덩을 확인하길 바란다.

반응형

+ Recent posts