MinIO 도커 컴포즈 설정과 버킷 자동 생성

MinIO 도커 허브, 공홈에는 podman 사용을 권장하고 있어서
podman compose 로 해볼까 했으나
지금 하고 있는 프로젝트에서 podman 이 아닌 도커를 쓰고 있어서
도커 컴포즈로 만들어 보았다.
인프라 관련 세팅을 잘해두면 협업하는 개발자가 편하기 때문에
MinIO 도커에 띄우고 유저 생성하고 버킷 만들고 하는 과정을 자동화해 보았다.

MinIO 도커 컴포즈 스크립트

포트를 9000번과 9099번 두 개를 열고 있는데
9099번은 MinIO 서버 포트이고 9000번은 MinIO 콘솔 포트이다.
그래서 브라우저에서 MinIO 콘솔을 띄울때는 localhost:9000 을 두드리면 되고
버킷 생성, 파일 생성 등 서버와의 작업에는 localhost:9099 으로 통신하면 된다.
그리고 콘솔 로그인 정보는 MINIO_ROOT_USER 와 MINIO_ROOT_PASSWORD 를 설정하면
디폴트 설정을 오버라이딩 해버린다.

minio:
    # minio 콘솔 url : localhost:9000
    image: minio/minio
    ports:
      - "9000:9000"
      - "9099:9099"
    environment:
      # minio 콘솔 로그인 정보
      MINIO_ROOT_USER: IamUser
      MINIO_ROOT_PASSWORD: IamPassword
    command: server --address ":9099" --console-address ":9000" /data

MinIO Client 를 이용한 버킷 자동생성 스크립트

minio 서비스가 완료되어야 움직일 수 있기 때문에 디펜던시를 걸어놓았다.
명령어 부분을 살펴보자.
먼저 mc alias set 커맨드로 호스트, 유저 ID, 패스워드를 정의해 주는데,
유저 ID, 패스워드는 MinIO 서비스에서 설정한 루트 정보 즉 콘솔 로그인 정보를 넣으면 된다.
호스트 부분을 보면 localhost:9099 가 아니라 minio:9099 로 설정해 주고 있는데 왜일까?
도커 컴포즈 처음 사용할 때 정말 크게 당했던 기억이 있는데,
도커 컴포즈로 묶인 녀석들의 통신을 위해서 작성하는 스크립트의 호스트 이름은
IP 주소가 아니라 서비스 이름을 적어줘야 한다는 것이다.
별칭을 설정해 줬으니 별칭으로 작업을 계속 진행하자.
다음으로 mc mb 커맨드로 버킷을 생성해 준다.
test/test-bucket 은 [앞에서 정의한 별칭]/[버킷이름] 이다.

init_minio:
    image: minio/mc
    depends_on:
      - minio
    entrypoint: >
      /bin/sh -c "
      mc alias set test http://minio:9099 IamUser IamPassword --api S3v4;
      mc mb test/test-bucket;
      exit 0;
      "

AWS-SDK-GO-V2 를 사용하는 코드에서 실제로 사용해보기

MinIO 의 원래 의도대로라면 switch 를 쓰지 않는 것이 맞지만,
MinIO 에서 아직 V2 를 지원해 주고 있지 않다.
깃헙에 이슈가 올라오긴 했는데 개발자가 여유가 생기면 하겠다는 뉘앙스로 답변하고 클로즈 시켜버렸다.
어쩔 수 없이 로컬 개발환경 즉 MinIO 부분은 V1 방식으로, 프로덕션 부분은 V2 방식으로 나눠서 코딩해야 한다.
MinIO 부분에서 설정해줄 곳은 엔드포인트 부분이다.
PartitionID 는 아무 생각 없이 "aws" 로 설정하면 되고,
SigningRegion 도 아무 생각없이 아무거나 설정해주면 되고,
중요한 부분은 통신을 위한 URL 부분이다.
앞의 도커 컴포즈에서 설정한 대로 9099 포트를 사용하면 된다.

func newAWSConfig(cfg *config.Config) (aws.Config, error) {
	credential := credentials.NewStaticCredentialsProvider(cfg.AWS.AWSAccessKey, cfg.AWS.AWSSecretKey, "")

	switch cfg.Server.Mode {
	case "dev":
		// MinIO 사용, MinIO 공식홈 가이드는 aws sdk go v1 이라 v2 에 맞게 수정하면서 약간 복잡해 짐
		endPointResolver := aws.EndpointResolverWithOptionsFunc(func(service, region string, options ...interface{}) (aws.Endpoint, error) {
			return aws.Endpoint{
				PartitionID:       "aws",
				URL:               "http://localhost:9099",
				SigningRegion:     cfg.AWS.AWSRegion,
				HostnameImmutable: true,
			}, nil
		})
		awsCfg, err := awsConfig.LoadDefaultConfig(
			context.TODO(),
			awsConfig.WithCredentialsProvider(credential),
			awsConfig.WithEndpointResolverWithOptions(endPointResolver),
		)
		if err != nil {
			return aws.Config{}, err
		}
		return awsCfg, nil
	case "prod":
		awsCfg, err := awsConfig.LoadDefaultConfig(
			context.TODO(),
			awsConfig.WithCredentialsProvider(credential),
			awsConfig.WithRegion(cfg.AWS.AWSRegion),
		)
		if err != nil {
			return aws.Config{}, err
		}
		return awsCfg, nil
	default:
		return aws.Config{}, errors.New("invalid environment")
	}
}

베어메탈 시절에는 전문가가 반드시 있어야 했기 때문에 웹 개발자가 서버나 인프라를 만질 일이 거의 없었지만
인프라를 코드로 설정할 수 있고, 자동화할 수 있는 클라우드 시대가 도래하고 나서 웹 개발자들 일이 늘어났다.
규모가 크고 좋은 곳에는 SRE 나 DevOps 분들이 있겠지만 그렇지 못한 환경의 직장이 훨씬 많을 것이다.
어찌 됐든 협업할 때 '너 오라클 어떻게 깔았어? 나는 왜?' 이런 일들 없이
docker compose up 하나만 두드리면 끝나는 좋은 시대인 것은 확실하다.