Docker Image 를 로컬 파일로 저장하기

컨테이너 이미지를 활용하여 빠르게 서버 환경을 구축하는 건 요즘 흔한 일이다.

다만 오프라인 환경에서는 외부 환경에서 이미지를 가져올 수 없기 때문에, 컨테이너 이미지를 활용하기 위해서는 파일로 변환하여 폐쇄망으로 자료 전송하는 등의 과정이 필요하다.

## 외부 image 를 로컬 파일로 저장

```
## (online) - image download
docker pull {image}:{tag} --platform={platform}

## (online) - image -> tar package
docker save {image}:{tag} > {image_filename}.tar
```

## 로컬 파일 image 를 로드

```
## (offline) load image from package
docker load -i {image_filename}.tar

## (offline) check image loaded
docker image ls 
```

이 블로그의 인기 게시물

서버에서 Client IP 를 추출하는 여러가지 방법

서비스 요구사항에 따라 Client IP 가 필요한 상황이 있다. 보안을 위해서 Client IP 를 확인하여 접근을 허용할 수 있다. 허용되지 않은 IP 의 경우 접근을 막을 수 있다. 로그 요구사항으로 어떤 사용자가 접근하고 있는 지를 기록하기 위해 Client IP 를 남겨야 할 수 있다. 하지만 사용자나 서비스의 네트워크 구성에 따라서 Client IP 를 추출하는 것이 쉽지 않을 수 있다. 프록시가 있어 직접 연결한 Client 를 실제 사용자로 판단할 수 없는 경우가 그렇다. 프록시 뒤에 있는 사용자를 찾으려고 노력하면 Client IP 를 숨기거나 우회하기 위해서 변조를 시도하는 상황을 마주하게 된다. 그래서 Client IP 를 추출하기 위한 여러 방안들을 아래에 정리하게 되었다. 결론부터 먼저 말하면, 일반적인 상황에서 나는 `X-Forwarded-For` 의 가장 오른쪽의 Public IP 를 Client IP 로 판단하기로 했다. 믿을 수 없는 목록 중에서 신뢰할 수 있으면서 간단하고, 빠른 방법이라 생각하기 때문이다. 하지만 여러 방안들을 조사했을 때, 어떤 상황에서는 사용할 수 있는 지, 또 어떤 지점이 문제가 되는 지 생각해볼 수 있었다. 그래서 고민했었던 여러 방안들을 소개하려고 한다. ### Remote IP 프록시가 없는 간단한 구조의 서비스라면 서버에 연결된 Remote IP 를 Client IP 로 추출할 수 있다. 하지만 Remote IP 가 실제 사용자의 IP 라는 확신이 없다면, Client IP 로 사용하기 어렵다. 사용자 네트워크 구성에서 proxy 가 있다면, 서버에 연결된 Remote IP 는 실제 사용자의 Client IP 가 아닐 수 있다. 여기에서 서비스 요구사항에 대한 명확한 정의가 필요해질 수 있다. 사용자 네트워크의 사설 IP 를 추출해야 하는 지, 아니면 공인 IP 를 추출해야 하는 지 정의가 필요하다. 사설 IP 는 서비스의 입장에서 큰 의미가 없기 때문에, 보통 공인 IP...

자세한 내용 보기

정보 검색 평가 지표 ( + RAGAS)

> https://amitness.com/posts/information-retrieval-evaluation 글을 읽고 정리한 문서입니다. ## 지표의 목적 상위 N 결과가 얼마나 우수한지 어떻게 평가할 것 인가? ### Binary relevance - 문서에 대한 관련성을 `있다 / 없다` 로만 판단한다. - 현재 Ranking model 이 query 에 대해서 5개의 각각의 문서 관련도는 `[1, 0, 1, 0, 1]` 로 나타낼 수 있다. (*binary*) ## Order-unaware metrics ### Precision@k $$ Precision@k = \frac{ true\ positives@k}{(true\ positives@k) + (false\ positives@k)} $$ - 이 메트릭은 상위 K 결과의 관련 항목 수를 정량화합니다. - 추출된 k 랭크 문서 중에서 관련 있는 문서의 갯수 예시) *Precision@2* ### Recall@k $$ Recall@k = \frac{ true\ positives@k}{(true\ positives@k) + (false\ negatives@k)} $$ - 이 메트릭은 쿼리에 대한 모든 실제 관련 결과 중에서 몇 개의 실제 관련 결과가 표시되었는지 알려줍니다. - 전체 관련 있는 문서 갯수 중에서 k 랭크 내에 추출된 관련 있는 문서의 갯수 예시) *Recall@2* ### 참고: Precision 과 Recall 의 집합관계 - A = 모델에서 문서가 관련 있다고 예측한 영역 (예측) - B = 실제 관련 있는 문서가 있는 영역 (정답) - b 영역 = True Positive 로 모델이 추출한 관련 문서 중 실제 관련 있는 문서가 있었던 영역 모델이 반환한 결과 중에서 실제 관련도 있는 문서를 추출한 비율이 precision, 실제 관련 있는 문서 목록 중 model 이 올바르게 문서를 추출한 비율이 recall 이라고 할 수 있다...

자세한 내용 보기

다형성을 사용하도록 조건문 다시 작성하기

객체 지향 프로그래밍을 하다 보면, 필연적으로 상속 구조를 활용하게 되는데요. 이 때, 서비스 로직에서 실제 인스턴스 타입별로 어떤 코드 실행을 다르게 해주어야 하는 경우가 발생합니다. 고민하지 않고 단순히 인스턴스 별 조건분기문으로 코드를 작성하게 되면, 새로운 요구사항이 추가될 때마다 코드의 변경이 많아질 수 있습니다. 또 그런 변경들이 프로그램의 로직을 복잡하게 만들어낼 수 있는데요. 오늘은 이런 상황에서 조건문을 사용하지 않고, 다형성을 활용할 수 있는 방안에 대해서 살펴보겠습니다. ## 상황 - 새를 나타내는 `Bird` 클래스가 있습니다. 이 `Bird` 객체를 API 응답으로 내려주기 위해서는 `BirdResult` 객체로 변형되어야 합니다.BirdResult 는 내부 객체와 API 응답 필드들을 분리하기 위하여 사용하고 있는 DTO 입니다. - 이 `BirdResult` 를 생성하기 위해 `Builder` 를 사용하고 있습니다. - `Bird` 로부터 `BirdResult` 의 각 응답 필드를 세팅하는 메서드는 아래와 같습니다. ``` // BirdResult.java /** * Bird 값을 주입한다. (As-is) * @param bird * @return Builder */ public Builder bird(Bird bird) { this.id = bird.getId(); this.name = bird.getName(); this.type = bird.getType(); // ... return this; } ``` ## 새로운 요구사항 - `Bird` 는 이제 새로운 하위타입들로 나누어져야 합니다. (`Canary` , `Duck` , `MockingBird` ) - 각 하위 타입에 따라서 `BirdResult` 에 채워주어야 할 필드가 달라...

자세한 내용 보기

개발일기

이 블로그 검색