움직이는 월e

[CryptoPP] SRP 프로토콜 (Secure Remote Password Protocol)

로파이 — Sat, 30 Aug 2025 15:35:12 +0900

클라이언트- 서버 모델에서 유저 이름 (username)과 비밀번호 (password)를 기반으로 인증된 키를 교환하는 프로토콜. (PAKE)

간단히 요약하자면 Client 와 Server가 username, password를 알고 있을 때, 공개 키만을 교환하여 동일한 비공개 키를 각 진영에서 만들 수 있다.

절차
공통 알고 있는 사항 username (I), password (p)

H (A,...,Z) = 해시 알고리즘 (ex SHA-512) =

A, ... , Z 까지 숫자에 대한 해시

N = 충분히 큰 소수
g = 2 ; g ^ x mod N group을 만들어내는 generator
k = H (M, g) ; SRP 파라미터

1. 유저 DB 생성 (서버)

유저 s = salt, 특정 길이의 랜덤 문자열을 생성

비밀 키 x = H (s, I, p);

패스워드 검증기 v = pow (g, x, N); 비밀 번호를 직접 들고 있지 않는다.

2. 공개 키 교환

Client, Server에 각각 a, b는 public key를 만들기 위한 salt 생성

Client -> Server : username, client_public_key (A)

Server -> Client : server_public_key (B), user_salt (s)

3. 세션 키 생성

Client 는 Server 로 부터 받은 salt를 이용하여 비밀 키를 생성
x = H(s, I, p)

서버 공개 키 B 를 조합하여 세션 키를 생성
Client의 세션 키 = F_c ( a, B, x, N, k)

Server는 클라이언트 공개키 A를 이용하여 세션키를 생성
Server의 세션 키 = F_s (A, b, v, N)

이 때, Client 세션 키와 Server 세션 키는 같아야한다.

추가적으로 Client 쪽에서 client_proof_key를 Server에 제공하여 Server가 Client를 검증할 수 있고
Server가 server_proof_key를 Client에 제공하여 Client가 Server를 검증할 수 있다.

SPR 예제

SRP.h

#pragma once

#include <string>
#include <memory>

namespace Crypto {
	class SRP final {
	public:
		class Client;
		class Server;

		SRP(const std::string_view& username, const std::string_view& password);
		SRP(const std::string_view& username, const std::string_view& password, const std::string_view& user_salt);
		~SRP();

		static void Initialize(); // Initialize SRP parameters (N, g)

		Client GetClient();
		Server GetServer();

	private:
		class Impl;
		std::unique_ptr<Impl> impl_;

	public:
		class Client {
		public:
			Client(Impl* impl);
			~Client();

			std::string GetPublicKey();
			bool CalculateSessionKey(const std::string_view& server_public_key);
			const std::string& GetSessionKey() const { return session_key_; }

			std::string CalculateClientProof(const std::string_view& server_public_key);
			bool VerifyServerProof(const std::string_view& server_public_key, const std::string_view& server_proof);

		private:
			Impl* impl_;
			std::string a_hex_;
			std::string A_hex_;
			std::string session_key_;
		};

		class Server {
		public:
			Server(Impl* impl);
			~Server();

			std::string GetPublicKey() const;
			std::string GetUserSalt() const;

			bool CalculateSessionKey(const std::string_view& client_public_key);
			const std::string& GetSessionKey() const { return session_key_; }

			std::string CalculateServerProof(const std::string_view& client_public_key, const std::string_view& client_proof);
			bool VerifyClientProof(const std::string_view& client_public_key, const std::string_view& client_proof);

		private:
			Impl* impl_;
			std::string b_hex_;
			std::string B_hex_;
			std::string session_key_;
		};
	};
}

SRP.cpp

#include "stdafx.h"
#include "SRP.h"
#include "Core/Crypto/Hex.h"
#include "Core/Crypto/Salt.h"
#include "Core/Crypto/Hash/SHA512.h"
#include "Core/Crypto/Internal/Prime.h"
#include <cryptopp/integer.h>
#include <cryptopp/nbtheory.h>
#include <cryptopp/modarith.h>
#include <cryptopp/osrng.h>

namespace Crypto {
	class SRPParam : public System::Singleton<SRPParam> {
	public:
		SRPParam(Protection) {
			GeneratePrime(2048, 1024, &N);
		}

		CryptoPP::Integer N;
		CryptoPP::Integer g = 2;
	};

	class SRP::Impl {
	public:
		Impl(const std::string_view& username, const std::string_view& password) 
			:
			username_(username),
			salt_hex_(ToHex(Salt(16))) {
			const CryptoPP::Integer* SRP_N = &SRPParam::GetInstance().N;
			const CryptoPP::Integer* SRP_g = &SRPParam::GetInstance().g;

			// k = H(N | g)
			std::string k_source = FORMAT("{}:{}", ToHex(*SRP_N), ToHex(*SRP_g));
			std::string k_hash = SHA512::Compute(k_source);
			std::string k_hex = ToHex(k_hash);
			k_ = CryptoPP::Integer(k_hex.c_str());

			std::string private_key_source = FORMAT("{}:{}:{}", salt_hex_, username, password);
			std::string private_key_hash = SHA512::Compute(private_key_source);
			std::string private_key_hex = ToHex(private_key_hash);

			x_ = ToInteger(private_key_hex);
			verfier_ = CryptoPP::ModularExponentiation(CryptoPP::Integer(2), x_, *SRP_N);
		}

		Impl(const std::string_view& username, const std::string_view& password, const std::string_view& user_salt)
			:
			username_(username),
			salt_hex_(user_salt) {
			const CryptoPP::Integer* SRP_N = &SRPParam::GetInstance().N;
			const CryptoPP::Integer* SRP_g = &SRPParam::GetInstance().g;
			// k = H(N | g)
			std::string k_source = FORMAT("{}:{}", ToHex(*SRP_N), ToHex(*SRP_g));
			std::string k_hash = SHA512::Compute(k_source);
			std::string k_hex = ToHex(k_hash);
			k_ = CryptoPP::Integer(k_hex.c_str());
			std::string private_key_source = FORMAT("{}:{}:{}", salt_hex_, username, password);
			std::string private_key_hash = SHA512::Compute(private_key_source);
			std::string private_key_hex = ToHex(private_key_hash);
			x_ = ToInteger(private_key_hex);
			verfier_ = CryptoPP::ModularExponentiation(CryptoPP::Integer(2), x_, *SRP_N);
		}

		~Impl() {
		}

	private:
		friend class SRP::Server;
		friend class SRP::Client;

		std::string username_;
		CryptoPP::Integer k_; // k = H(N | g)
		CryptoPP::Integer x_; // x = H(s | H(I | ":" | P))
		CryptoPP::Integer verfier_; // v = g^x % N
		std::string salt_hex_;
	};

	SRP::SRP(const std::string_view& username, const std::string_view& password)
		:
		impl_(std::make_unique<Impl>(username, password))  {

	}

	SRP::SRP(const std::string_view& username, const std::string_view& password, const std::string_view& user_salt)
		:
		impl_(std::make_unique<Impl>(username, password, user_salt))
	{
	}

	SRP::~SRP() = default;

	void SRP::Initialize() {
		SRPParam::GetInstance();
	}

	SRP::Client SRP::GetClient() {
		return SRP::Client(impl_.get());
	}

	SRP::Server SRP::GetServer() {
		return Server(impl_.get());
	}

	SRP::Client::Client(Impl* impl)
		:
		impl_(impl) {
		const CryptoPP::Integer* SRP_N = &SRPParam::GetInstance().N;
		const CryptoPP::Integer* SRP_g = &SRPParam::GetInstance().g;

		a_hex_ = ToHex(Salt(16));
		CryptoPP::Integer a = ToInteger(a_hex_.c_str());
		A_hex_ = ToHex(CryptoPP::ModularExponentiation(*SRP_g, a, *SRP_N));
	}

	SRP::Client::~Client() = default;

	std::string SRP::Client::GetPublicKey() {
		return A_hex_;
	}

	bool SRP::Client::CalculateSessionKey(const std::string_view& server_public_key/*B_hex*/) {
		const CryptoPP::Integer* SRP_N = &SRPParam::GetInstance().N;

		CryptoPP::Integer A = ToInteger(A_hex_);
		CryptoPP::Integer B = ToInteger(server_public_key);

		if (B % (*SRP_N) == 0) {
			return false;
		}

		std::string u_hex = SHA512::Compute(FORMAT("{}:{}", A_hex_, server_public_key));

		CryptoPP::Integer u = ToInteger(u_hex);
		CryptoPP::Integer a = ToInteger(a_hex_);

		CryptoPP::Integer exp = (a + u * impl_->x_);
		CryptoPP::Integer base = (B - impl_->k_ * impl_->verfier_);
		CryptoPP::Integer S = CryptoPP::ModularExponentiation(base, exp, *SRP_N);
		session_key_ = ToHex(SHA512::Compute(ToHex(S)));

		return true;
	}

	SRP::Server::Server(Impl* impl)
		:
		impl_(impl) {
		const CryptoPP::Integer* SRP_N = &SRPParam::GetInstance().N;
		const CryptoPP::Integer* SRP_g = &SRPParam::GetInstance().g;
		b_hex_ = ToHex(Salt(16));
		CryptoPP::Integer b = ToInteger(b_hex_);
		CryptoPP::Integer gb = CryptoPP::ModularExponentiation(*SRP_g, b, *SRP_N);
		CryptoPP::Integer k_mul_v = (impl_->k_ * impl_->verfier_);
		CryptoPP::Integer B = (k_mul_v + gb) % (*SRP_N);
		B_hex_ = ToHex(B);
	}

	SRP::Server::~Server() = default;

	std::string SRP::Server::GetPublicKey() const {
		return B_hex_;
	}

	std::string SRP::Server::GetUserSalt() const { 
		return impl_->salt_hex_; 
	}

	bool SRP::Server::CalculateSessionKey(const std::string_view& client_public_key/*A_hex*/) {
		const CryptoPP::Integer* SRP_N = &SRPParam::GetInstance().N;

		std::string u_hex = SHA512::Compute(FORMAT("{}:{}", client_public_key, B_hex_));
		CryptoPP::Integer A = ToInteger(client_public_key);
		CryptoPP::Integer B = ToInteger(B_hex_);
		CryptoPP::Integer u = ToInteger(u_hex);
		if (A % (*SRP_N) == 0) {
			return false;
		}

		CryptoPP::Integer exp = ToInteger(b_hex_);
		CryptoPP::Integer base = (A * CryptoPP::ModularExponentiation(impl_->verfier_, u, *SRP_N));
		CryptoPP::Integer S = CryptoPP::ModularExponentiation(base, exp, *SRP_N);
		session_key_ = ToHex(SHA512::Compute(ToHex(S)));

		return true;
	}

	std::string SRP::Client::CalculateClientProof(const std::string_view& server_public_key/*B_hex*/) {
		// M1 = H(A | B | S_client)
		return SHA512::Compute(FORMAT("{}:{}:{}", A_hex_, server_public_key, session_key_));
	}

	bool SRP::Client::VerifyServerProof(const std::string_view& server_public_key/*B_hex*/, const std::string_view& server_proof) {
		// M2 = H(A | M1 | S_server)
		std::string M1 = CalculateClientProof(server_public_key);
		std::string expected_server_proof = SHA512::Compute(FORMAT("{}:{}:{}", A_hex_, M1, session_key_));
		return expected_server_proof == server_proof;
	}

	std::string SRP::Server::CalculateServerProof(const std::string_view& client_public_key/*A_hex*/, const std::string_view& client_proof) {
		// M2 = H(A | M1 | S_server)
		return SHA512::Compute(FORMAT("{}:{}:{}", client_public_key, client_proof, session_key_));
	}

	bool SRP::Server::VerifyClientProof(const std::string_view& client_public_key/*A_hex*/, const std::string_view& client_proof) {
		// M1 = H(A | B | S_client)
		std::string expected_client_proof = SHA512::Compute(FORMAT("{}:{}:{}", client_public_key, B_hex_, session_key_));
		return expected_client_proof == client_proof;
	}
}

유닛 테스트로 알아보는 절차

TEST_METHOD(SRPTest)
{
	Crypto::SRP srp_server("username", "password");
	auto server = srp_server.GetServer();

	Crypto::SRP srp_client("username", "password", server.GetUserSalt());
	auto client = srp_client.GetClient();

	std::string client_public_key = client.GetPublicKey();
	std::string server_public_key = server.GetPublicKey();

	bool client_session_ok = client.CalculateSessionKey(server_public_key);
	bool server_session_ok = server.CalculateSessionKey(client_public_key);

	Assert::IsTrue(client_session_ok);
	Assert::IsTrue(server_session_ok);

	std::string client_session_key = client.GetSessionKey();
	std::string server_session_key = server.GetSessionKey();

	Assert::AreEqual(client_session_key, server_session_key);

	std::string client_proof = client.CalculateClientProof(server_public_key);
	bool server_proof_ok = server.VerifyClientProof(client_public_key, client_proof);
	std::string server_proof = server.CalculateServerProof(client_public_key, client_proof);
	bool client_proof_ok = client.VerifyServerProof(server_public_key, server_proof);

	Assert::IsTrue(client_proof_ok);
	Assert::IsTrue(server_proof_ok);
}

참고: Secure Remote Password protocol - Wikipedia

[CryptoPP] SHA hash

로파이 — Sat, 30 Aug 2025 14:55:04 +0900

임의의 바이트 열에 대하여 해시를 계산할 수 있는 알고리즘

미국 국가 안보국 NSA 에서 설계 하였으며, SHA-1, SHA-2 가 차례로 개발됌.
SHA-2 그룹 중 SHA-256/512 해시 알고리즘을 많이 사용하며 뒤에 붙은 숫자는 다이제스트 (결과 바이트 수)를 만들어내는 해시 함수를 의미한다.

ex) SHA-256은 4바이트 * 8 (32 * 8), SHA-512의 경우 8바이트 * 8 (64 * 8)

단방향 압축 기능 - Wikipedia

데이비스 - 마이어 Davies-Meyer의 단 방향 압축 함수 PlainText (H_i-1) + Key(m_i) -> CipherText (Hi) 를 만들어내는 구조가 기본 바탕이며 Merkle-Damgard 구성 을 더해 충돌 방지 암호화 해시 함수를 설계되었다.

성능
원본 바이트를 추적하기 어렵게 하는 역상 저항성 (preimage resistance)과 두 plaintext의 해시 충돌이 적도록 하는 충돌 저항성 (collision resistance)에 대해 실용적인 보안 수준을 제공

[by gpt]

1. Preimage Resistance (역상 저항성)
• 정의: 주어진 해시 값 H에 대해, 원래 입력값 M을 찾는 것이 계산적으로 어려운 성질입니다. 즉, H = Hash(M)인 M을 찾는 것이 매우 어렵다는 것을 의미합니다.
• 문장에서의 의미:
• SHA-256의 경우, 64라운드 중 52라운드에 대해 역상 저항성을 깨는 공격이 존재합니다.
• SHA-512의 경우, 80라운드 중 57라운드에 대해 역상 저항성을 깨는 공격이 존재합니다.
• 이는 전체 라운드 수보다 적은 라운드에서만 공격이 가능하다는 것을 의미하며, 전체 라운드에서는 여전히 안전하다는 것을 암시합니다.
---
2. Collision Resistance (충돌 저항성)
• 정의: 서로 다른 두 입력값 M1과 M2에 대해, 동일한 해시 값 H를 생성하는 것이 계산적으로 어려운 성질입니다. 즉, Hash(M1) = Hash(M2)인 M1과 M2를 찾는 것이 매우 어렵다는 것을 의미합니다.
• 문장에서의 의미:
• SHA-256의 경우, 64라운드 중 46라운드에 대해 충돌 저항성을 깨는 공격이 존재합니다.
• 이는 전체 라운드 수보다 적은 라운드에서만 충돌 저항성을 깨는 것이 가능하며, 전체 라운드에서는 여전히 안전하다는 것을 암시합니다.
---
3. 공격의 의미
• "공격이 가능하다"는 의미:
• 특정 라운드 수에서 공격이 가능하다는 것은, 이 라운드 수에서 해시 알고리즘의 보안 강도가 약화된다는 것을 의미합니다.
• 그러나 전체 라운드 수에서 공격이 불가능하다면, 해당 해시 알고리즘은 여전히 안전하다고 간주됩니다.
• 공격의 실제 영향:
• 이 공격들은 이론적인 연구 결과에 기반하며, 실제로는 매우 높은 계산 비용이 필요합니다.
• 따라서, SHA-256과 SHA-512는 여전히 실용적인 보안 수준을 제공합니다.

CryptoPP 간단한 예제

#include <cryptopp/sha.h>
#include <cryptopp/hex.h>
#include <cryptopp/filters.h>

std::string SHA512::Compute(const std::string_view& source) {
	std::string digest;
	CryptoPP::SHA512 hash;
	CryptoPP::StringSource(source.data(), true,
		new CryptoPP::HashFilter(hash,
			new CryptoPP::HexEncoder(
				new CryptoPP::StringSink(digest))));
	return digest;
}

[웹 서비스] OAuth 2.0

로파이 — Sat, 28 Dec 2024 19:02:05 +0900

OAuth 2.0

외부 웹 서비스 계정을 이용하여 해당 서비스 권한을 간접적으로 획득하여 나의 웹 서버에서 활용하고자 할 때,

외부 웹 서비스에 나의 웹 서버를 인증하는 프로토콜

나의 서비스가 유저의 구글, 야후, 카카오 등 대표 가능한 웹 서비스의 이메일 주소를 이용하고자 한다.

유저의 이메일 주소를 알 수 있다면 나의 웹 사이트에서는 따로 이메일 가입을 할 필요 없이 해당 외부 웹 서비스 계정 정보를 이용하여 유저를 특정하고 계정으로 사용할 수 있을 것 이다.

참여자

서비스를 이용하고자 하는 유저 (resource owner) : 내 서비스가 참조하고자 하는 자원 (이메일 주소)를 소유한다.

내 서비스 (client) : 유저의 정보를 활용하고자하는 주체. 웹 서비스가 될 수도 있고 앱 어플리케이션 자체가 요구할 수도 있다.

인증 서버 (authorization server) : 내 서비스를 등록하고 유저의 요청이 왔을 때, 나의 서비스에 의해 요청된 것인 지 인증하고 나의 서비스에 접근 토큰(access token)을 제공한다.

자원 서버 (resource server): 외부 서비스 중 실제 유저의 정보를 저장하고 있는 서버이다. 나의 서비스는 제공 받은 접근 토큰을 사용해 해당 서버에 직접 API를 요청한다.

간단한 절차

1. 서비스 등록

OAuth2.0을 사용하여 인증을 하기 위해 인증 서비스에 내 서비스를 등록한다.

외부 서비스에는 유저가 계정 인증을 완료했을 때, 획득한 접근 토큰을 가지고 호출할 콜백 주소 redirect-uri를 등록한다.

외부 서비스는 내 서비스를 등록하고 인증 서버의 클라이언트로서 사용할 ClientID와 Client Secret을 제공받는다.

이는 외부 인증 서버로의 ID와 패스워드 역할을 하고 내 서비스는 이를 config 등으로 관리해둔다.

예시) Google Auth

구글에 내 서비스를 등록하면, ClientID와 Secret을 확인할 수 있다. Secret은 응답 내용 등에서 유저에 직접 노출되지 않도록 주의한다.

2. 인증 코드 요청

이제 라이브 중 인 내 서비스가 유저 외부 계정 정보를 이용하고자 한다.

유저는 외부 서비스를 통한 자신의 정보를 제공하기 위해 내 서비스로 OAuthURL를 요구한다.

내 서비스는 유저에게 외부 서비스 계정 로그인 웹 페이지로 연결되는 OAuthURL 주소를 제공한다.

이 떄 내 서비스는 "scope" 허락 받을 유저의 정보에 대한 범위를 의미하는 scope를 지정해서 OAuthURL을 만든다.

scope는 이메일 주소, 캘린더, 프로필 등 자원에 대한 접근 범위를 지정한다.

웹 서비스라면 OAuthURL로 리다이렉션을 하여 로그인 페이지가 바로 보이게 하거나 앱이라면 Provider의 웹 서비스 앱을 열어 리다이렉션이 될 수도 있다.

이 때 유저가 요청하는 주소의 형식은 대략 다음과 같다.

https://${auth_server_address}?&client_id=${clientID}&redirect_uri=${redirectURL}?scope=${scope}

유저가 인증 서버를 통해 계정 인증을 완료하면, 인증 서버는 해당 redirect_uri와 client_id가 등록된 서비스인 지 확인한다.

유저가 요청한 정보와 내 서비스가 등록한 정보가 일치하지 않는다면, http code가 200이 아닌 에러 응답을 보낼 것이다.

인증 서버를 통해 정상 인증이 완료되면, 302 코드에 의해 Redirect이 다시 일어나며 응답 헤더에 적힌 Location으로 리다리에션된다.

이 때, 요청 주소에 인증 토큰 (인증 코드) code 파라미터 내용이 인증 서버에 첨부된 것을 확인할 수 있다.

*이 때, 접근 토큰을 직접 제공하지 않고 접근 토큰과 교환 가능한 인증 코드를 제공한다.

3. 인증 코드 제공 및 접근 토큰 교환

유저의 인증 코드를 받은 이후 내 웹 서비스는 인증 코드, ClientID, Client Secret을 바탕으로 접근 토큰을 교환한다.

4. 접근 토큰을 사용한 유저 정보 조회 및 서비스 제공

성공적으로 접근 토큰을 교환하였다면, 내 웹 서비스는 허용된 범위 내에서 유저에 대한 정보를 조회할 수 있는 API를 resource server에 직접 요청할 수 있게 된다.

resource server가 제공하는 API를 통해 내 웹 서비스는 유저의 정보를 제공 받는다.

접근 토큰에는 유효 시간이 있기 때문에 필요하다면, 내 서비스는 접근 토큰을 갱신해야 한다.

crsf token의 사용

OAuth 2.0 인증 과정을 보면, 인증 서버에 state 파리미터로 스트링값이 포함된 것을 볼 수 있다.

인증 서버로의 요청 시에 csrf 토큰 값을 state 파라미터로 전달하며, 인증 서버는 crsf 토큰을 다시 참조할 수 있도록 유저 리다이렉션 주소에 파라미터로 첨부한다.

Cross Site Request Forgery CSRF 크로스 사이트 요청 공격

공격자가 같은 겉모습을 가진 악의성 웹 사이트를 유저에게 사용하게 함으로써
특정 요청에 대한 내용을 변경하여 공격자의 의도대로 웹 서버로 요청하게 하는 행위 이다.

이 때, 웹 서비스는 자신이 제공한 웹 페이지가 현재 유저가 바라보는 웹 페이지와 일치하는 지 그리고 사용자의 요청이 자신의 웹 서비스 페이지로부터 온 것인지 확인할 필요가 있다.

웹 서비스는 CSRF 토큰을 발행하여 세션이나 보안 쿠키에 설정하여 사용자의 다음 요청에서 해당 토큰이 존재하고 일치하는 지 확인한다. 이에 따라 요청된 내용이 해당 토큰이 발행된 페이지에서 온 것 인지 검증한다.

예제) go 웹 서비스로 작성하여 google OAuth2.0을 사용하는 예제

package main

import (
	"crypto/rand"
	"encoding/base64"
	"encoding/json"
	"log"
	"net/http"

	"github.com/gin-gonic/gin"
	"github.com/spf13/viper"

	"golang.org/x/oauth2"
	"golang.org/x/oauth2/google"
)

type AuthProvider struct {
	Provider     string
	ClientId     string
	ClientSecret string
}

type AuthProviderConfig struct {
	Google AuthProvider
}

var (
	autoProviderConfig AuthProviderConfig
	oauth2Config       oauth2.Config
	oauth2State        string
)

func generateStateString() (string, error) {
	b := make([]byte, 32) // 32 bytes
	_, err := rand.Read(b)
	if err != nil {
		return "", err
	}
	return base64.URLEncoding.EncodeToString(b), nil
}

func initConfig() error {
	viper.SetConfigName("config")
	viper.AddConfigPath(".")
	viper.SetConfigType("yaml")

	return viper.ReadInConfig()
}

func loadAuthProvider() {
	if viper.IsSet("auth-provider.google") {
		clientId := viper.GetString("auth-provider.google.client-id")
		clientSecret := viper.GetString("auth-provider.google.client-secret")
		redirectUri := viper.GetString("auth-provider.google.redirect-uri")
		scopes := viper.GetStringSlice("auth-provider.google.scopes")

		autoProviderConfig.Google = AuthProvider{
			Provider:     "google",
			ClientId:     clientId,
			ClientSecret: clientSecret,
		}
		log.Printf("Google auth provider loaded with client id: %s", clientId)

		oauth2Config = oauth2.Config{
			ClientID:     clientId,
			ClientSecret: clientSecret,
			RedirectURL:  redirectUri,
			Scopes:       scopes,
			Endpoint:     google.Endpoint,
		}
	}
}

func getPing(c *gin.Context) {
	c.JSON(http.StatusOK, gin.H{"message": "server is healthy"})
}

func userAuthCallbackGoogle(c *gin.Context) {
	code := c.DefaultQuery("code", "")
	state := c.DefaultQuery("state", "")

	if code == "" || state == "" {
		c.JSON(http.StatusBadRequest, gin.H{"error": "missing code or state"})
		return
	}

	// csrf attack check
	originalState, err := c.Cookie("oauth2_state")
	if err != nil || originalState == "" {
		c.JSON(http.StatusBadRequest, gin.H{"error": "missing state cookie"})
		return
	}

	// exchange the code for a token
	token, err := oauth2Config.Exchange(c, code)
	if err != nil {
		c.JSON(http.StatusInternalServerError, gin.H{"error": "failed to exchange token"})
		return
	}

	// use the token to fetch user information
	client := oauth2Config.Client(c, token)
	resp, err := client.Get("https://www.googleapis.com/oauth2/v2/userinfo")
	if err != nil {
		c.JSON(http.StatusInternalServerError, gin.H{"error": "failed to fetch user info"})
		return
	}
	defer resp.Body.Close()

	// parse user data
	var user map[string]interface{}
	if err := json.NewDecoder(resp.Body).Decode(&user); err != nil {
		c.JSON(http.StatusInternalServerError, gin.H{"error": "failed to parse user info"})
		return
	}

	c.JSON(http.StatusOK, gin.H{"email": user["email"], "name": user["name"]})
}

func userAuthGoogle(c *gin.Context) {
	// generate a random state string
	oauth2State, err := generateStateString()
	if err != nil {
		c.JSON(http.StatusInternalServerError, gin.H{"error": "failed to generate state"})
		return
	}

	// set cookie with state
	// use secure when in production as https is required
	c.SetCookie("oauth2_state", oauth2State, 3600, "", "", false, true)

	authURL := oauth2Config.AuthCodeURL(oauth2State, oauth2.AccessTypeOnline)

	log.Printf("Redirecting to %s", authURL)

	c.Redirect(http.StatusFound, authURL)
}

func main() {

	readConfigErr := initConfig()
	if readConfigErr != nil {
		log.Fatalf("Error reading config file, %s", readConfigErr)
	}

	loadAuthProvider()

	port := viper.GetString("server.port")
	mode := viper.GetString("server.mode")

	gin.SetMode(mode)

	router := gin.Default()
	router.GET("/ping", getPing)
	router.GET("/auth/google", userAuthGoogle)
	router.GET("/auth/google/callback", userAuthCallbackGoogle)

	router.Run("localhost:" + port)
}

main.go

server:
  port: "8080"

logging:
  level: "info"
  format: "json"

auth-provider:
  google:
    client-id: your-client-id
    client-secret: your-client-secret
    redirect-uri: "http://localhost:8080/auth/google/callback"
    scopes:
      - "openid"
      - "email"
      - "profile"

config.yml

Docker In Action 12. First-class configuration abstractions

로파이 — Sat, 14 Dec 2024 22:39:22 +0900

도커 config와 secret에 대해 알아본다.

Configuration 구성 설정 파일은 어플리케이션을 실행할 때 필요한 설정 파일을 의미하며, DB 커넥션 스트링, 각종 제약과 비즈니스 로직에 사용되는 설정값을 파일을 통해 설정하는 것을 의미.

12.1 구성 설정 배포와 관리

도커 서비스는 어플리케이션을 정의하는 이미지에 의존하는 것처럼 configuration 리소스에 의존한다. 구성 설정이나 시크릿 파일이 누락되었다면, 어플리케이션은 실행 되지 않거나 잘 못 된 행동을 유발한다.

12.2 어플리케이션과 구성 설정 분리

greetings 서비스는 "Hello World!"를 서로 다른 언어로 출력하는 서비스이다. 이 서비스의 개발자는 유저의 요청이 오면 한 인사말을 응답으로 주고 싶어한다. 번역가를 통해 검증 받은 인사말들을 다음과 같은 config.common.yml 파일에 설정하였다.

config.common.yml

greetings:
	- 'Hello World!'
	- 'Hola Mundo!'
	- 'Hallo Welt!'

서비스는 실제 배포 환경을 인식하여 기본 인사말에 더해 특정 인사말들을 추가하길 원한다. 개발팀은 dev, stage, 그리고 prod 환경을 관리하고 dev 환경에서는 다음과 같은 구성을 사용하고자 한다.

config.dev.yml

greetings:
	- 'Orbis Terrarum slave!'
	- 'Bonjour le monde!'

우리가 배포할 때 필요한 것은 배포 환경에 따른 구성 설정 파일을 컨테이너 내부로 주입하는 것이다.

greetings 서비스는 다음 git 소스에 정의된 Docker Compose 파일을 사용하여 도커 스웜에 스택으로 배포할 것이다.
GitHub - dockerinaction/ch12_greetings: This repository contains the greetings service example used in Chapter 12 of Docker in Action, 2ed.

배포에 사용할 docker.compose.yml

# Docker Compose file reference: https://docs.docker.com/compose/compose-file/
version: '3.7'

configs:
  env_specific_config:
    file: ./api/config/config.${DEPLOY_ENV:-prod}.yml

services:

  api:
      image: ${IMAGE_REPOSITORY:-dockerinaction/ch12_greetings}:api
      ports:
        - '8080:8080'
        - '8443:8443'
      user: '1000'
      configs:
        #- env_specific_config # short form mounts the config file in as a file named `env_specific_config`
        - source: env_specific_config
          target: /config/config.${DEPLOY_ENV:-prod}.yml
          uid: '1000'
          gid: '1000'
          mode: 0400 #default is 0444 - readonly for all users
      secrets: []
      environment:
        DEPLOY_ENV: ${DEPLOY_ENV:-prod}

환경변수 DEPLOY_ENV에 따라 적절한 config 파일 i.e. config.dev.yml을 사용하여 어플리케이션이 해당 파일을 주입 받아 실행할 수 있도록 배포 설정을 하였다.

config resource 다루기

Docker config resource는 Swarm 클러스터 객체로 어플리케이션의 런타임 필요로 저장할 때 사용한다.

configs:
  env_specific_config:
    file: ./api/config/config.${DEPLOY_ENV:-prod}.yml

가장 윗 부분에 정의된 configs 엔트리에 env_specific_config는 환경 변수 DEPLOY_ENV에 결정된 파일 이름을 가리킨다.
도커 스택이 생성될 때 해당 파일은 config resource 로써 도커 클러스터 내부에 저장된다.

services:

  api:
      image: ${IMAGE_REPOSITORY:-dockerinaction/ch12_greetings}:api
      ports:
        - '8080:8080'
        - '8443:8443'
      user: '1000'
      configs:
        #- env_specific_config # short form mounts the config file in as a file named `env_specific_config`
        - source: env_specific_config
          target: /config/config.${DEPLOY_ENV:-prod}.yml
          uid: '1000'
          gid: '1000'
          mode: 0400 #default is 0444 - readonly for all users

서비스 정의에 configs 엔트리에서 볼륨을 지정하듯 config resource를 주입한다.

해당 파일의 uid, gid 그리고 접근 권한이 설정된다. (readonly to user)

어플리케이션 배포

환경변수를 설정하고 어플리케이션 greetings_dev를 배포한다.

$env:DEPLOY_ENV="dev" # on windows
DEPLOY_ENV=dev # on linux
docker stack deploy --compose-file docker-compose.yml greetings_dev

localhost:8080 포트의 웹 주소로 들어가면 다음 응답을 받을 수 있다.

localhost:8080/greeting 요청에 인사말이 응답으로 오는 지 확인한다.

Hello World!
Hallo Welt!
Orbis Terrarum salve!

도커 config 관리하기

docker config는 subcommand로 create, inspect, ls, rm을 지원한다.

docker config inspect greetings_dev_env_specific_cofnig로 예제로 만들어진 config resource를 자세히 출력한다.

해당이름은 도커 스택의 이름 greetings_dev를 prefix로 한다.

Data는 실제 config 데이터를 base64 인코딩한 값이며 비밀성 유지를 지키지지는 않는다. 단지 도커 스웜 클러스터사이의 저장과 이동을 위해 인코딩되었다. 스웜은 클러스터 중앙 저장소에서 꺼내어 서비스 태스크의 파일 시스템에 배치한다.

도커 config 는 create와 rm 만 지원하며, 업데이트는 허용하지 않는다.

따라서 config 내용만 업데이트하여 같은 배포를 실행하면 실패하게 된다.

docker stack deploy --compose-file docker-compose.yml greetings_dev

도커 서비스와 의존성

서비스는 이제 이미지와 config resource에 의존한다.

config resource가 존재하지 않거나 변경되었다면 서비스는 시작하지 않는다.

Depdendency	application_image	config_resource
service greetings_dev	dockerinaction/ch12_greetings:api	greetings_dev_env_specific_config

서비스 inspection

docker service inspect --format '{{ json .Spec.TaskTemplate.ContainerSpec.Configs }}' greetings_dev_api

실행하고 있는 greetings_dev_api 서비스가 참조하는 ConfigID는 생성된 config resource의 unique ID를 가리킨다.

서비스 정의에 config가 바인딩되어 정의되어 있는 것이다.

[{"File":{"Name":"/config/config.dev.yml","UID":"1000","GID":"1000","Mode":256},"ConfigID":"qss45j65h01kjpwxw1npjvz08","ConfigName":"greetings_dev_env_specific_config"}]

config는 이미 사용중이라면 삭제가 불가능하고 이미 있는 이름으로 생성도 불가능하다.

config를 변경하고자 한다면, config 도 새로운 리소스 이름으로 실행해야한다. 마치 이미지에 새로운 배포 태그를 붙여 새로운 배포를 실행하는 것과 같다.

t0 : first application deployment with greetings_dev_env_specific_config

t1 : changes configuration as greetings_dev_env_specific_config_v1

t2 : update features and change configuration as greetings_dev_env_specific_config_v2

12.3 Secrets, 특별한 구성 설정

Secret은 비밀번호나 API key, private encryption 등 절대 외부로 노출되면 안되는 설정 값들을 의미한다.

도커 bootstrap 과정 중 서비스 인증 과정

어플리케이션이 Secret과 함께 실행하지 않는다면 외부 인증 주체가 어플리케이션을 인증하고 secret을 제공하는 수단을 사용해야한다. 이러한 수단으로써 도커는 부트스트랩 과정에서 신뢰있는 시크릿 제공을 가능하게 한다. 클러스터링 서비스 과정에서 암호화된 통신을 사용하여 자신의 서비스 Service ID로 클러스터링 매니저에 인증을 하기 때문이다.

도커 스웜은 Service ID를 기반으로 어떤 Secret을 Service 태스크가 접근할 수 있는 지 결정한다.

도커는 tmpfs 파일 시스템을 사용하여 읽기만 가능한 인메모리 파일 시스템을 컨테이너에 마운트한다. 기본값으로 secrets은 /run/secrets 경로에 마운트 된다.

어플리케이션은 어떤 파일을 읽을 지 알고 있고 도커로 부터 제공받은 secret 파일을 읽어 비밀번호나 API_KEY와 같은 것을 사용할 수 있게 한다.

greetings 서비스 예제)

HTTPS 서비스를 위하여 CA의 private key를 docker secret으로 public key을 docker config로 주입한다.

$env:DEPLOY_ENV="prod" # on windows
DEPLOY_ENV=prod # on linux

docker stack deploy --compose-file docker-compose.yml --compose-file docker-compose.prod.yml greetings_prod

위를 실행하면 다음과 같은 오류가 발생한다.

configs:
  ch12_greetings_svc-prod-TLS_CERT_V1:
    external: true

secrets:
  ch12_greetings-svc-prod-TLS_PRIVATE_KEY_V1:
    external: true

docker-compose.prod.yml 파일에는 config ch12_greetings_svc-prod-TLS_CERT_V1와 ch12_greetings-svc-prod-TLS_PRIVATE_KEY_V1가 자동 생성이 아닌 "external" 전역에 정의된 값을 사용하도록 되어 있기 때문이다.

docker secret create ch12_greetings-svc-prod-TLS_PRIVATE_KEY_V1 "./api/config/insecure.key"
docker config create ch12_greetings_svc-prod-TLS_CERT_V1 "./api/config/insecure.crt"

docker secret create와 docker config create를 사용하여 적절한 secret과 config를 정의한다.

다시 서비스를 시작하면, https 로 시작한 greetings_prod_api를 확인할 수 있다.

서비스 로그를 확인하여 참조한 https CA 인증서의 private key와 public key 위치를 확인한다.

https://localhost:8443 웹 주소에서 정상 출력됨을 확인한다.

요약

- 어플리케이션은 배포되는 환경에 맞게 동작을 변경해야한다.

- 도커 config와 secret 자원은 배포되는 환경에 맞게 동작되도록 어플리케이션을 조작하도록 한다.

- secrets는 비밀성을 요구하는 특별 설정값들이다.

- 도커 스웜은 trust 체인을 사용하여 도커 서비스가 시크릿이 특정 어플리케이션에 제공될 수 있음을 인증한다.

- 도커는 config와 secret 제공을 위해 tmpfs 파일 시스템을 사용한다.

- 배포 프로세스는 자동화를 위해 config와 secret resource에 이름을 붙이는 명명법으로 관리하는 것을 권고한다.

Docker In Action 11. Services with Docker and Compose

로파이 — Sat, 14 Dec 2024 16:35:14 +0900

도커 서비스 구축

서비스란

어떠한 프로세스 process, 기능 functionality 혹은 데이터가 네트워크를 통해 이용가능할 때 서비스라고 할 수 있다.

도커 스웜 노드를 통한 서비스 구축 및 Docker Compose 파일 작성을 통해 선언적 방식으로 서비스를 실행하는 방법을 알아본다.

11.1 Service "Hello World"

hello-world 서비스 : 간단한 hello-world 컨테이너를 하나 실행하는 명령어 예제.

docker swarm init // establish service abstraction
docker service create
	--publish 8080:80
    --name hello-world
    dockerinaction/ch11_service_hw:v1 // starts local server listens on 8080

도커 서비스는 docker swarm mode가 실행될 때 가능하다. docker service create 명령어는 컨테이너 실행과 비슷하다.

docker swarm init : 도커 엔진은 도커 서비스 오케스트레이션 (서비스를 구성하는 노드를 유지하는 도구) 기능을 제공하는 docker swarm node를 실행한다. 내부적으로 오케스트레이션을 위한 데이터베이스를 시작하는 것을 포함한다.

docker service create는 8080 포트에서 서비스하는 컨테이너를 하나 실행한다.

도커 스웜은 "hello-world 컨테이너 실행"을 하는 "task" 작업을 정의서를 가지고 있다.

이 작업을 통해 실제 컨테이너 하나가 실행되도록 Swam Node는 서비스를 유지한다.

docker service ps 를 통해 실행중인 서비스 상태를 확인한다.

서비스의 복구와 복제 기능

서비스는 실행되는 노드가 목표로하는 노드 수를 유지하려고 한다. 현재 유지해야하는 노드 (컨테이너)가 한 개이고 이 노드가 중단된다면, 서비스는 노드를 하나 다시 실행한다.

REPLICAS 1/1 로 표기되어 있는 의미는 한 개의 노드를 반드시 유지하도록 되어 있다는 뜻이다.

1) 컨테이너 하나를 강제로 중지한다.

2) 잠시후 docker service ps hello-world를 통해 서비스 상태를 확인한다.

중지한 컨테이너 기록이 있고 그 이후에 다시 컨테이너를 새로 실행한 것을 확인할 수 있다.

DESIRED STATE, CURRENT STATE

Desired State는 유저가 서비스를 통해 유지되어야할 상태를 나타내고 Current State는 현재 상태를 의미한다. 오케스트레이션 도구는 서비스 상태를 추적하여 상태 변화를 감지한다.

docker service inspect 서비스 인스펙션

서비스 이름, Service ID, 버전, 타임스탬프 등등 서비스 상태를 표시한다.

노드 스케일 설정 변경

docker service scale hello-world=3

도커 스웜으로 실행중인 서비스 노드 수를 조절 가능하며 효력은 즉시 일어난다. 필요한 컨테이너 수 만큼 실행이 되며 각 컨테이너 이름은 hello-world.1, hello-world.2, hello-world.3 을 prefix로 하여 실행된다.

docker service ps

docker container ls

자동화된 롤아웃

새로운 실행 파일 교체 등 서비스 업데이트를 위한 명령을 알아본다.

docker service update \
	--image dockerinaction/ch11_service_hw:v2 \
	--update-order stop-first \
	--update-parallelism 1 \
	--update-delay 30s
	hello-world

docker service update는 새로운 이미지 ch11_service_hw:v2 로 실행되는 컨테이너로 교체하는 작업을 시작한다.

각 작업은 하나씩 기존 서비스를 중지하고 새로운 이미지로 실행하는 서비스를 시작한다.

각 서비스 업데이트 사이에 30초의 딜레이가 존재한다.

서비스 업데이트가 모두 완료되면, Service converaged 사인이 출력되고 정상 처리되었음을 알 수 있다.

서비스 헬스 체크와 롤백

비정상적인 서비스를 업데이트 했을 때, 서비스 업데이트 사항을 롤백할 수 있는 기능을 제공한다.

1) 영원히 실행하지 않는 서비스를 하나 실행한다.

docker service update \
	--image dockerinaction/ch11_service_hw:start-failure \
	hello-world

상태가 "실패" 상태로 유지되고 있음을 확인한다.

2) 롤백 처리를 실행한다.

docker service update --rollback hello-world

서비스 배포 시 실패가 감지 되면 자동 롤백처리를 실행하는 옵션을 사용한다.

docker service update --update-failure-action rollback --update-max-failure-ratio 0.7 --image dockerinaction/ch11_service_hw:start-failure hello-world

헬스 체크

v2 이미지는 헬스 체크 기능을 내장하고 있다. 내장 기능 httpping 프로그램을 통해 컨테이너가 localhost, '/' 경로에서 정상 응답 200을 받고 있다는 것을 확인하고 컨테이너 상태가 "health" 임을 확인할 수 있다.

해당 이미지의 도커 파일에는 다음과 같이 헬스 체크를 하도록 명시되어 있다.

HEALTHCHECK --interval=10s CMD ["/bin/httpping"]

헬스 체크 기능이 없는 이미지를 사용하면 더 이상 컨테이너 상태는 "healthy" 인 지 알 수 없게 된다.

docker service update \
	--update-failure-action rollback \
	--image dockerinaction/ch11_service_hw:no-health \
	hello-world

서비스 중단

docker service rm hello-world

예제로 사용한 서비스를 중단한다.

Compose V3를 사용한 도커 서비스 환경 구축

명령적 방식이 아닌 파일을 사용하여 구축할 서비스를 정의하고 이를 통해 서비스를 실행하는 방법을 알아본다.

docker stack

도커 스택은 모든 도커 서비스, 볼륨, 네트워크 그리고 다른 설정 요소들의 구성을 의미한다.

Compose V3 파일은 도커 스택을 정의하며, YAML 포맷으로 작성된다.

database.yml 예제

version: "3.7"
volumes:
  pgdata:
services:
  postgres:
    image: dockerinaction/postgres:11-alpine
    volumes:
      - type: volume
        source: pgdata
        target: /var/lib/postgresql/data
    environment:
      POSTGRES_PASSWORD: example
  
  mariadb:
    image: dockerinaction/mariadb:10-bionic
    environment:
      MYSQL_ROOT_PASSWORD: example
    
  adminer:
    image: dockerinaction/adminer:4
    ports:
      - 8080:8080
    deploy:
      replicas: 2

volumes : 도커의 볼륨을 정의한다.

services : 도커의 서비스를 정의한다.

각 엔트리의 구성 요소는 postgres, mariadb, adminer 서비스를 구성하는 것을 알 수 있따.

각 서비스는 사용할 이미지, 볼륨, 환경 변수, 포트, 복제 노드 수 등을 작성하여 실행할 서비스의 설정을 구성한다.

도커 스택 배포하기

docker stack deploy -c database.yml my-databases

서비스 상태 확인하기

docker service ls 서비스 상태 확인하기

docker stack ps로 스택 상태를 확인할 수 있다.

yml 파일을 수정하여 adminer 서비스의 replicas 수를 조정하고 다시 배포해본다.

조정된 수로 실행된 adminer 서비스 수를 확인할 수 있다.

로드밸런싱, 서비스 디스커버리, 그리고 네트워크

adminer 웹 서비스는 8080 포트를 통해 접근 가능하다는 것을 알 수 있다.

실제 컨테이너는 두 개가 실행되고 있으며 컨테이너에 할당된 포트 번호는 8080과는 다르다.

도커는 virtual IP를 생성하여 서비스를 중재하고 들어오는 요청을 내부 실행되는 컨테이너에게 적절히 전달하는 로드 밸런싱을 수행한다. 호스트의 인터페이스로 부터 요이 들어오면 서비스의 VIP로 포워딩을 한다.

my-databases 서비스의 네트워크 구성

ingress 네트워크

docker service inspect my-databases_adminer 를 실행하면, 다음과 같이 일부분에서 호스트 인터페이스와 연결된 ingress 네트워크와 두 개의 adminer 서비스 VIP들이 있는 것을 확인할 수 있다.

docker network inspect ingress

ingress 네트워크를 자세히 보면, 두 adminer 컨테이너에 대한 Endpoint와 ingress 네트워크의 Endpoint를 확인할 수 있다.

이는 도커 내부에서 사용되는 주소이며 로드 밸런서가 외부 요청을 전달할 주소이다. 외부 호스트 인터페이스와 연결된 ingress-sbox는 내부 IP로 10.0.0.2/24 주소를 갖는다.

스택 기본 네트워크 : my-databases_default

스택에 참여하는 모든 서비스는 기본 네트워크를 통해 통신이 가능하다. 각 컨테이너의 자신의 Endpoint를 가진 고유 네트워크는 스택 기본 네트워크와 연결되어 있다.

docker network inspect my-databases_default를 통해 상세 내용을 확인할 수 있다.

해당 IPv4는 도커 컨테이너의 IP 혹은 로드 밸런서가 바라보는 내부 요청을 전달할 타겟 주소들이다.

실행 중인 postgres 컨테이너 1개

my_databases_postgres.1 : 10.0.2.40/24

실제 postgres 서비스의 IP 인터페이스는 VIP로 생성되며, 다음과 같이 확인할 수 있다.

docker service inspect my-databases_postgres

VIP는 로드 밸런서에 의해 관리되며, VIP를 통한 연결은 postgres service 복제 노드로 전달된다.

docker network ls를 통해 도커 스웜이 생성한 두 네트워크를 직접 확인 가능하다.

default 네트워크를 대체하려면 Compose 파일의 networks 엔트리에 명시하라

version: "3.7"
networks:
	foo:
		driver: overlay
volumes:
  pgdata:
services:
  postgres:
    image: dockerinaction/postgres:11-alpine
    volumes:
      - type: volume
        source: pgdata
        target: /var/lib/postgresql/data
    networks:
    	- foo
    environment:
      POSTGRES_PASSWORD: example
  
  mariadb:
    image: dockerinaction/mariadb:10-bionic
    networks:
    	- foo
    environment:
      MYSQL_ROOT_PASSWORD: example
    
  adminer:
    image: dockerinaction/adminer:4
    networks:
    	- foo
    ports:
      - 8080:8080
    deploy:
      replicas: 2

요약

서비스는 네트워크를 통해 제공되는 프로세스, 기능, 데이터를 의미하낟.

스웜과 같은 오케스트레이터는 유저가 설정한 상태를 충족시키기 위해 서비스, 볼륨, 네트워크를 유지한다.

오케스트레이터는 복제, 복원, 배포, 헬스 체크, 롤백 기능을 수행한다.

목표 상태는 유저가 시스템으로 요구하는 달성해야할 상태를 의미하며, docker compose 파일로 작성 가능하다.

compose 파일은 YAML 형식이다.

compose 파일은 도커 서비스, 볼륨, 네트워크를 정의하며 스택을 만드는 정의서이다.

Docker In Action 9. Public and private software distribution

로파이 — Mon, 9 Dec 2024 22:31:52 +0900

공개 혹은 비공개 소프트웨어 배포

9.1 배포 방법 선택 하기

여러 사항을 고려하여 개발 실정에 맞는 배포 방법을 선택하게 된다.

배포 스펙트럼

배포 스펙트럼

왼쪽으로 기술될 수록 배포 방식은 단순하나 제한적인 방식으로 제공된다.

오른쪽으로 기술될 수록 배포 방식은 복잡하나 커스터 마이즈가 쉽게 되므로 유연하다.

선택 기준

배포 방식을 선택함에 있어 기준점이 될 수 있는 요소를 나열 해본다.

Cost 비용

대게 낮은 비용이 최선의 선택이다. 프로젝트에 주어진 예산에 따라 결정된다.

Visibility 가시성

해당 프로젝트는 공개되어서는 안된다.

Transportation 전송

배포 환경의 네트워크 전송 속도와 대역폭은 배포 방식을 선택하는데 영향을 줄 수 있다.

Longevity 지속 가능성

공개되지 않은 배포 방식을 공개된 방식으로 전환했을 때 문제 없이 진행될 것 인가.

Availability 가용성

언제나 사용가능한 가

Access Control 접근 제어

프로젝트 빌드 이미지를 다른 서드 파티에 의해 변경하거나 접근하는 것을 허용할 것인가

Integrity 무결성

신뢰성 있고 일관성 있는 배포 방식. 중간 자 공격과 같은 해킹에 영향이 없도록 함.

Confidentiality 비밀성

프로젝트가 허용하는 공개 범위 내에서 이미지가 배포되는 가.

Expertise 전문성

도구에 대한 전문 지식을 요구하는가. 배포 방법이 복잡해질 수록 더 높은 전문성을 요하게 된다.

호스팅된 저장소를 통한 배포 hosted registries

Docker registries는 docker pull 명령어로 가져올 수 있는 이미지를 관리하는 저장소이다.

그러한 이미 호스팅되고 있는 서비스를 통해 이미지를 배포하는 방식.

예시)

Docker Hub

Quay.io

다음 HelloWorld.df 를 작성하고 이미지를 빌드하여 docker registry에 배포한다.

FROM busybox:latest
CMD echo 'Hello World!'

docker image build -t <insert Docker Hub username>/hello-dockerfile -f HelloWorld.df .

<docker Hub username> 부분은 Docker Hub에 가입하여 생성한 username을 기입한다.

로컬 cli에서 docker login을 통해 배포에 대한 인증을 수행한다.

해당 방식은 비용 효율적(무료)이며 모든 사람에게 공개된 레지스트리를 사용한다. 접근 제어 또한 용이한데, 공개된 사용자들에게는 읽기 가능하고 개인, 조직 단위로 이미지를 업데이트할 수 있는 권한을 가진다. 데이터는 호스팅된 서비스를 통해 일관성있게 유지되며 큰 전문성 없이 유지보수가 가능하다.

반대로 비공개용 프로젝트에는 부적합하다.

비공개 저장소

비공개 저장소는 공개 저장소와 모든 면이 비슷하다. docker registry API는 공개와 비공개 저장소에 대한 구분을 거의 하지 않는다.

차이점은 docker image pull 이나 docker container run 을 비공개 저장소의 이미지를 지정할 때, docker login과 같은 인증 절차를 필요로 한다는 것이다.

공개되지 않기 때문에 비밀성에 대한 충족 사항이 만족된다.

개인 저장소를 도입 private registries

개인 저장소

docker registry를 격리된 네트워크에서 서비스하여 직접 저장소 서비스를 구축하고 해당 저장소에 이미지를 배포하는 방식이다. Docker registry는 Apache License 2 하에 배포되는 오픈 소스이다. Docker registry를 직접 구축하여 서비스하여 비용 절감과 서비스 구현 비용을 줄일 수 있을 것 이다.

이미지 배포에 대한 지엽적인 특징을 가지며 호스팅된 서비스와 이미지 소스 배포 사이의 중간 특징을 가진다.

레지스트리에 대한 커스터 마이징과 환경에 맞는 배포 설정을 가능하게 한다.

예시)

도커 레지스트리에서 이미지를 받아 로컬 저장소에 푸시하는 예시

docker image pull dockerinaction/ch9_registry_bound
docker image ls -f "label=dia_exercise=ch9_registry_bound"
docker image tag dockerinaction/ch9_registry_bound localhost:3000/dockerinaction/ch9_registry_bound
docker image push localhost:5000/dockerinaction/ch9_registry_bound

개인 저장소는 localhost:5000에서 서비스 중이다.

직접 수동으로 이미지 배포

고유 배포 인프라가 있는 경우

FTP 파일전송 형태나 HTTPS와 같은 웹 서비스로 직접 이미지를 다운로드하여 배포하는 방식이다.

도커 이미지를 사용하여 배포하는 경우 그리고 중간 파일 서버를 통해 이미지를 배포하는 방식을 예로 들 수 있다.

이미지는 export를 통해 tar 파일로 내보내지고 FTP 서버를 통해 배포되는 인프라에 전송된다. 전송된 파일은 다시 이미지로 import되어 컨테이너를 실행하는 데 쓰이게 된다.

이미지 소스-배포 워크플로우

기존 배포 인프라를 사용하여 이미지 소스를 배포

Git과 같은 버전 컨트롤 시스템을 사용하여 소스로 부터 직접 빌드 및 배포를 하는 방식이다.

1) git 저장소로 부터 소스를 받는다.

2) 이미지를 빌드 한다.

3) 빌드한 이미지를 저장소로 내보낸다.

요약

여러 사항을 고려하여 배포 방식을 선택하여 프로젝트에 도입하라

hosted public repositories는 프로젝트 가시성, 무료, 낮은 전문성 요구를 가진다.

hosted private repositores는 소규모 프로젝트에 적합하고 접근 제어를 용이하게 한다.

FTP와 같은 file-sharing system을 사용하면 이미지를 파일로서 배포할 수 있다.

이미지 소스 배포는 유연하나 복잡하게 만들려면 얼마든지 가능하다. 기존에 있는 인프라를 사용하여 배포한다.

Docker In Action 8. Building image automaticall with Dockerfiles

로파이 — Sun, 8 Dec 2024 21:20:25 +0900

Dockerfile 이란

docker 이미지를 빌드하는 데 쓰이는 지시사항들의 모음

8.1 Dockerfile을 이용하여 ubuntu-git 빌드하기

Dockerfile이라는 이름으로 파일을 만들고 다음 내용을 작성한다.

FROM ubuntu:latest
LABEL maintainer="dia@allingeek.com"
RUN apt-get update && apt-get install -y git
ENTRYPOINT ["git"]

이미지 빌드하기

docker buildx build --tag ubuntu-git:auto .

auto 태그로 된 이미지가 존재하는 것을 볼 수 있다.

설명

- FROM : 기본이 되는 이미지

- LABEL : key=value 형태로 label을 부여한다.

- RUN : 컨테이너를 실행한 후 프로그램 실행 명령어를 나열한다.

- ENTRYPOINT : 프로그램 진입점을 나타낸다.

Dockerfile에 새로운 내용을 추가한다면, 새로운 레이어가 추가된 이미지가 빌드된다.

Docker 이미지 빌드 시스템은 캐싱을 이용하여 단계별 레이어가 이미 빌드된 캐시를 사용할 수 있다면, 빠르게 빌드할 수 있다.

FROM ubuntu:latest
LABEL maintainer="dia@allingeek.com"
RUN apt-get update && apt-get install -y git
ENTRYPOINT ["git"]
RUN this will not work

- Run this will not work를 추가해본다.

- 그 전 레이어에 대한 캐싱을 사용하기 때문에 이전 빌드보다 빠르다.

- --no-cache 옵션을 사용하면 캐시 사용 없이 빌드 한다.

8.2 도커 파일 핵심

메타 데이터 지시사항

.dockerignore 파일을 작성하면 해당 리스트에 있는 파일들은 이미지 빌드 시 컨테이너 내부로 복사를 방지한다.

.dockerignore

mailer-base.df
mailer-logging.df
mailer-live.df

mailer-base.df 예시

FROM debian:buster-20190910
LABEL maintainer="dia@allingeek.com"
RUN groupadd -r -g 2200 example && \
    useradd -rM -g example -u 2200 example
ENV APPROOT="/app"\
    APP="mailer.sh" \
    VERSION="0.6"
LABEL base.name="Mailer Archetype" \
      base.version="${VERSION}"
WORKDIR $APPROOT
ADD . $APPROOT
ENTRYPOINT ["/app/mailer.sh"]
EXPOSE 33333

- LABEL은 이미지나 컨테이너에 메타 데이터를 제공한다.

- WORKDIR : 기본 작업 디렉토리

- EXPOSE : 도커 컨테이너 외부로 공개할 포트 번호를 지정한다.

- ENTRYPOINT : 프로그램 진입점을 의미하며 컨테이너 내부에서는 /bin/sh -c 'exec ./mailer.sh' 를 실행한다.

ENTRPOINT를 명시할 경우 CMD나 docker container run을 통해 명령어를 주입할 경우 무시되므로 주의.

mailer-base:0.6으로 이미지를 빌드해두자.

docker buildx build -t dockerinaction/mailer-base:0.6 -f mailer-base.df .

Filesystem 관련 사항

로깅 프로그램을 위한 mailer-logging.df 도커 파일 예시

FROM dockerinaction/mailer-base:0.6
RUN apt-get update && \
    apt-get install -y netcat
COPY ["./log-impl", "${APPROOT}"]
RUN chmod a+x ${APPROOT}/${APP} && \
    chown example:example /var/log
USER example:example
VOLUME ["/var/log"]
CMD ["/var/log/mailer.log"]

COPY : 이미지 빌드 파일 시스템으로 부터 컨테이너 내부로 복사

VOLUME : 이미지 파일 시스템에 볼륨을 생성 및 할당

CMD : ENTRYPOINT와 유사하나 커스텀한 명령어를 실행할 경우 지정

log-impl 폴더를 만들고 하위에 mailer.sh 쉘 스크립트를 작성한다.

mailer-base 이미지에 지정한 mailer.sh 스크립트 실행을 할 수 있다.

docker image build -t dockerinaction/mailer-logging -f mailer-logging.df .

컨테이너를 빌드한 이미지 mailer-logging로부터 실행한다.

mailer-live.df 작성하기

Amazon Web Servcice의 Simple Email Service를 이용하는 mailer-live.df를 작성해본다.

FROM dockerinaction/mailer-base:0.6
ADD ["./live-impl", "${APPROOT}"]
RUN apt-get update && \
    apt-get install -y curl netcat python && \
    curl "https://bootstrap.pypa.io/get-pip.py" -i "get-pip.py" && \
    python get-pip.py && \
    pip install awscli && \
    rm get-pip.py && \
    chmod a+x "${APPROOT}/${APP}"
USER example:example
CMD ["mailer@dockerianction.com", "pager@dockerinaction.com"]

- ADD : COPY와 유사하지만 URL을 지정할 경우 원격지 소스로 부터 파일을 받아 복사한다.

마찬가지로 live-impl 폴더를 생성하고 적절한 SES API를 호출하는 mailer.sh를 작성한다.

8.3 다운 스트림 빌드 타임 동작 주입하기

ONBUILD COPY [".", "/var/myapp"]
ONBUILD RUN go build /var/myapp

ONBUILD 동작은 해당 이미지를 기본으로 하는 다운 스트림 이미지가 실제로 빌드될 때, 동작하는 방식이다.

upstream.df

FROM busybox:latest
WORKDIR /app
RUN touch /app/base-evidence
ONBUILD RUN ls -al /app

 docker buildx build -t dockerinaction/ch8_onbuild -f upstream.df .

RUN ls -al /app 을 실행하지 않는다.

downstream.df

FROM dockerinaction/ch8_onbuild
RUN touch downstream-evidence
RUN ls -al

docker image build -t dockerinaction/ch8_onbuild_down -f downstream.df .

ch8_onbuild_down 이미지를 빌드할 때 기본이 되는 이미지를 가져온 직후 ONBUILD로 지정한 지시사항들이 적용된다.

8.4 관리 가능한 도커 파일 만들기

FROM debian:buster-20190910
ARG VERSION=unknown
LABEL maintainer="dia@allingeek.com"
RUN groupadd -r -g 2200 example && \
    useradd -rM -g example -u 2200 example
ENV APPROOT="/app"\
    APP="mailer.sh" \
    VERSION="0.6"
LABEL base.name="Mailer Archetype" \
      base.version="${VERSION}"
WORKDIR $APPROOT
ADD . $APPROOT
ENTRYPOINT ["/app/mailer.sh"]
EXPOSE 33333

ARG로 지정한 변수는 이미지를 빌드할 때 결정되는 값이다. 실제 빌드 시점에 결정되는 값에 쓰인다.

version=0.6;
docker buildx build -t dockerinaction/mailer-base:${version} \
	-f mailer-base.df \
    --build-arg VERSION=${version} \
    .

멀티 스테이지 빌드 옵션

한 도커 파일안에 빌드 stage를 둘 이상 지정하는 방식이다.

build와 runtime 빌드 stage가 있다면, runtime 빌드는 build stage에서 정의된 값을 가져올 수 있다.

# Builder stage
FROM go-lang:1-alpine as builder

# Install CA
RUN apk update && apk add ca-certificates

# Copy source into Builder
ENV HTTP_CLIENT_SRC=$GOPATH/src/dia/http-client/
COPY . $HTTP_CLIENT_SRC
WORKDIR $HTTP_CLIENT_SRC

# Build HTTP client
RUN CGO_ENABLED=0 GOOS=linux GOARCH=amd64 \
    go build -v -o /go/bin/http-client

# Runtime stage
FROM scratch as runtime
ENV PATH ="/bin"

COPY --from=builder /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/ca-certicifates.crt
COPY --from=builder /go/bin/http-client /http-client
ENTRYPOINT ["/http-client"]

builder 스테이지에서는 HTTPS 서비스를 위한 CA 인증서를 설치하고 http-client 실행 파일을 빌드한다.

runtime stage는 아무런 파일 시스템이 존재하지 않는 "scratch" 레이어에서 CA 인증서와 실행 파일만 복사하여 HTTPS 서비스를 실행하기 위한 이밎 빌드 단계 이다.

8.5 시작 스크립트 및 멀티 프로세스 컨테이너

이른 환경 검증하기

프로세스를 실행하기 전에 유효하지 않은 환경 설정이 발견되면, 더 진행하지 않고 빠른 종료를 권장한다.

그러한 시작 프로세스는 다음과 같은 값을 검증한 뒤, 원래 실행 파일을 실행하는 단계로 구성되어 있다.

- 별칭

- 환경 변수

- 시크릿

- 네트워크 접근 권한

- 네트워크 포트 사용 가능

- 볼륨

- 현재 유저

#!/bin/bash

set -e
if [ -n "$WEB_PORT80_TCP"]; then
    if [ -z $"WEB_HOST" ]; then
        WEB_HOST='web'
    else
        echo >$2 '[WARN]: Linked container, "web" overriden by $WEB_HOST.'
        echo >$2 "===> Connecting to WEB_HOST ($WEB_HOST)"
    fi
fi

if [ -z "$WEB_HOST" ]; then
    echo >$2 '[ERROR] : specify container to link;'
    exit 1
fi

# time to run original process
exec "$@"

초기화 프로세스

init process는 다중 프로그램을 관리하고, 댕글링된 프로세스를 정리하며 프로세스를 모니터링하고 실패 감지 시 자동 재시작 옵션을 제공하는 데 있다.

docker container run -it --init alpine:3.6 nc -l -p 3000

--init 옵션은 init 프로세스를 컨테이너 내부에서 실행할 수 있게 한다.

Docker In Action 7. Packaging software in images

로파이 — Fri, 6 Dec 2024 22:33:29 +0900

이미지 빌드를 통한 소프트웨어 패키징

7.1 컨테이너로 부터 도커 이미지 빌드

도커에서 union filesystem (UFS)기반의 마운트를 통해 컨테이너의 파일 시스템 기능을 제공한다.

7.1.1 Packaging "Hello, World"

예시) 나만의 이미지 빌드

-> 기존 이미지로 컨테이너를 실행하자.

-> 컨테이너의 파일 시스템에 변경 사항을 만들자.

-> 변경 사항을 이미지로 커밋 한다.

// 1. ubuntu:latest 이미지를 가져와 컨테이너를 실행한 후 HelloWorld 파일을 만든다.
docker container run --name hw_container ubuntu:latest touch /HelloWorld

// 2. 현재 컨테이너를 이미지로 커밋 하자
docker container commit hw_container hw_image

// 3. 기존 컨테이너를 정리
docker container rm -vf hw_container

// 4. 새로운 컨테이너에서 파일을 확인하자
docker container run --rm hw_image ls -l /HelloWorld

7.1.2 Git 기반 패키징 준비하기

Git 도구를 기존 이미지에 설치해서 패키징을 해보자

1) 도커 컨테이너를 하나 실행한다.

docker container run -it --name image-dev ubuntu:latest /bin/bash

2) 해당 컨테이너에 git을 설치한다.

apt-get update
apt-get -y install git

git version

exit을 통해 컨테이너 shell을 빠져 나온다.

7.1.3 파일 시스템 변경 사항을 확인해본다.

1) 파일 추가

docker container run --name tweak-a busybox:latest touch /HelloWorld
docker container diff tweak-a

- A : HelloWorld 파일이 추가되었다.

2) 파일 삭제

docker container run --name tweak-d busybox:latest rm /bin/vi
docker container diff tweak-d

- C: /bin 폴더에 변경 사항 존재

- D: /bin/vi 폴더가 삭제되었다.

3) 변경사항 만들기

docker container run --name tweak-c busybox:latest touch /bin/vi
docker container diff tweak-c

- C: /bin 폴더에 변경 사항 존재

- D: /bin/vi 폴더가 변경 사항 존재 (접근 시간 기록 등)

7.1.4 새로운 이미지 커밋

commit 명령어 사용하여 컨테이너로 부터 이미지 만들기

-a 옵션으로 저자 및 -m 메시지를 지정한다.

docker container commit -a "@dockerinaction" -m "Added git" image-dev ubuntu-git

docker images {image_name} 이미지 확인하기

해당 이미지에 git 도구가 있는 지 확인

docker container run --rm ubuntu-git git version

entrypoint 사용하기

해당 옵션을 지정하는 경우, 컨테이너 시작 시 해당 명령어를 기본으로 실행한다. 말 그대로 프로그램 진입점을 의미.

docker container run --name cmd-git --entrypoint git ubuntu-git

해당 컨테이너를 이미지로 커밋하고 다시 실행해보자. 지정한 entrypoint (git) 가 적용된다.

docker container commit -m "Set CMD git" -a "@dockerinaction" cmd-git ubuntu-git

docker contaienr rm -vf cmd-git

docker container run --name cmd-git ubuntu-git version

git version

7.1.5 이미지 속성 구성하기

commit을 한다는 것은 새로운 layer를 추가하는 것과 같다. commit으로 파일 시스템도 포함하지만 다음 실행 문맥과 관련된 메타 데이터도 layer에 포함된다

- 모든 환경 변수

- 기본 작업 폴더 경로

- 공개 포트

- 볼륨 정의

- 컨테이너 진입점

- 실행 명령어와 인수

다음 예시는 환경 변수를 이미지 레이어에 추가하는 예시이다.

docker container run --name rich-image-example -e ENV_EXAMPLE1=Rich -e ENV_EXAMPLE2=Example busybox:latest

docker conatiner commit rich-image-example rie

docker container run --rm rie /bin/sh -c "echo \$ENV_EXAMPLE1 \$ENV_EXAMPLE2"

rie 라는 이미지에는 ENV_EXAMPLE1, ENV_EXAMPLE2 환경 변수가 기록된다.

docker container run --name rich-image-example-2 --entrypoint "/bin/sh" rie -c "echo \$ENV_EXAMPLE1 \$ENV_EXAMPLE2"

docker container commit rich-image-example-2 rie

docker contianer run --rm rie

entrypoint를 "/bin/sh" 로 지정하고 명령어와 인수를 지정하는 -c 옵션을 사용한다.

해당 이미지에는 entrypoint와 명령어 메타 정보가 기록된다.

7.2 Docker 이미지와 레이어 더 알아보기

도커는 union fileysystem을 쓰기에 이미지 저자가 다음 중요사항을 알아야한다.

1) 저자는 파일의 추가, 삭제, 변경 내역은 이미지에 영향을 준다.

2) 저자는 레이어와 이미지와 관련된 레이어, 레파지토리, 태그와 연관 관계를 알아야한다.

mychange 파일을 생성하는 케이스

ubuntu:latest 이미지로부터 mod_ubuntu 컨테이너를 실행하고 mychage 파일을 만든다.

docker contaienr run --name mod_ubuntu ubuntu:latest touch /mychange

레이어 관점에서 동작

원본 이미지로 부터 새로운 변경 사항은 새로운 레이어 위에 쓰여진다.

- 추가, 삭제, 변경 모두 해당된다.

7.2.2 images, layers, repositories, and tags

images

union fileysystem은 레이어를 쌓으면서 만들어지며 항상 새로운 레이어가 위에 쌓인다.

현재까지의 변경사항으로 이미지 만들기

docker container commit mod_ubuntu

이제 새로운 이미지 Id는 위와 같다.

repository

repository에서 이미지 주소는 다음과 같다.

${registry_host}/${user_or_organization_name}/${short_name}
//docker.io/dockerinaction/ch3_hello_registry

만약 이 주소로 이미지를 pull 한다면, 항상 short_name에 해당하는 이미지의 latest 태그 버전을 가져온다.

태그와 함께 이미지 생성

mod_ubuntu 컨테이너를 mytag 태그에 해당하는 myuser/myfirst_repo 이미지로 만든다.

docker container commit mod_ubuntu myuser/myfirstrepo:mytag

해당 이미지를 latest 태그로 만든다. (태그 부분이 생략되면 항상 latest)

docker tag myuser/myfirstrepo:mytag myuser/mod_ubuntu

7.2.3 이미지 크기와 레이어 제한 관리

latest 태그를 다시 (2.7) 태그한다.

docker image tag ubuntu-git:latest ubuntu-git:2.7

ubuntu-git에서 git을 제거한 버전으로 이미지를 빌드하고 latest 태그를 부여한다.

docker container run --name image-dev2 --entrypoint /bin/bash ubuntu-git:latest -c "apt-get remove -y git"
docker container commit image-dev2 ubuntu-git:removed
docker image tag ubuntu-git:removed ubuntu-git:latest
docker images "ubuntu-git"

최신 latest 버전에서 이미지 크기가 증가한 것을 볼 수 있다.

UFS는 레이어에 파일을 삭제한 사실을 기록하기 때문에 전체 이미지 크기는 변경사항이 많을 수록 커진다.

docker image history로 이미지의 변경 내역을 알아본다.

다음 정보가 제공된다.

- 축약된 layer ID

- 레이어 나이

- 생성하는 컨테이너의 초기 명령어

- 레이어의 총 파일 사이즈

docker save로 이미지를 TAR 파일로 내보내서 다시 import 한 다면 이미지 사이즈가 줄어들 수 는 있으나, 이미지 메타 정보를 잃기 때문에 좋은 방법은 아니다.

브랜치 방법; 모든 변경사항을 되돌릴 수 있는 이전의 버전으로 돌아가서 이미지를 새로 만드는 것이다. ubuntu-git으로부터 git을 제거하였다면 ubuntu:latest 이미지에서 브랜칭을 하여 목적에 맞는 새로운 이미지를 만든다.

7.3 Exporting and importing flat filysystems

이미지를 파일로 내보내어 컨테이너나 UFS에 벗어난 문맥에서 관리하는 방법이 있다.

docker container export ${컨테이너 이름}

위 명령어는 컨테이너를 tar 파일로 내보내는 명령어이다.

docker container create --name export-test dockerinaction/ch7:packed:latest ./echo For Export
docker container export --output contents.tar export-test
docker container rm export-test
tar -tf contents.tar

실행 파일을 빌드한 이미지를 만들고 컨테이너로 실행하기 (hostsystem linux only)

다음 go 내용을 빌드해본다.

package main
import "fmt"

func main() {
	fmt.Println("hello, world!")
}

마운트한 파일을 빌드하는 다음과 같이 컨테이너를 실행한다.

docker container run --rm -v "$(pwd)":/usr/src/hello -w /usr/src/hello golang:1.9 go build -v

tar 명령어로 압축 파일을 만든다.

tar -cf static_hello.tar hello

다음 entrypoint를 지닌 docker_inaction/ch7_static 이미지로 만든다.

docker import -c "ENTRYPOINT [\"/hello\"]" - dockerinaction/ch7_static < static_hello.tar

빌드한 이미지를 실행해본다.

docker container run dockerinaction/ch7_static

hello 실행 파일을 진입점으로 하는 컨테이너가 실행된다.

7.4 버전 관리

도커로 다중 버전을 관리하기 위해서는 repository tagging이 중요하다.

1.9와 같은 숫자형 버전을 태그에 기입하여 어떤 라이브러리 버전을 사용하는 지 명시한다.

요약

- docker conatimer commit 명령어는 변경사항이 반영된 새로운 이미지를 만든다.

- 컨테이너가 commit된 경우 해당 이미지 구성 요소로 실행을 하게 된다.

- 이미지 레이어는 변경 내역이 적층된다.

- 이미지 사이즈는 구성 레이어 사이즈 의 합이다.

- docker image export, import는 이미지를 파일로 내보내고 파일로 부터 가져올 수 있다.

- docker image tag 명령어는 하나의 repository에서 여러 태그를 부여할 때 사용 가능 하다.

- stable 빌드 버전을 latest로 부여하라.

Docker In Action 6. Limiting risk with resource controls

로파이 — Wed, 4 Dec 2024 23:59:58 +0900

A Process In Isolation, 프로세스 단위의 고립성 수준을 이용하는 도커 컨테이너

도커 컨테이너의 8가지 주요 특징

MNT - filesystem access and structure

chroot() - Controls location of filesystem root

Cgroups - Resource protection

PID - Process identifiers and process capabilities

NET - Network access and structure

UTS - Host and domain name

USR - Usernames and identifiers

IPC - Communication by shared memory

6.1 자원 사용 가능 제어

주어진 물리 머신에서 CPU 사용과 메모리의 자원은 한정적이다.

6.1.1 메모리 제한

도커를 생성하거나 시작할 때 -m, --memory 옵션을 사용하면 메모리 사용 제한을 걸 수 있다.

docker container run -d
--name ch6_mariadb
--memory 256m
--cpu-shares 1024
--cap-drop net_raw
-e MYSQL_ROOT_PASSWORD=test
mariadb:5.5

메모리 제한 옵션은 해당 메모리 크기 만큼 예약을 하는 것이 아니다. 과다 사용만을 방지하는 옵션이다.

과다 사용이 탐지되는 경우 리눅스 커널에서 이를 효율적으로 방지한다.

어플리케이션마다 해당 과다 사용에 대한 에러 발생에 대한 처리가 필요할 수 있으며 얼마나 많은 메모리를 사용할 것 인가에 대한 판단이 필요하다.

6.1.2 CPU 제한

CPU 사용에 대해 옵션으로 제어할 수 있다.

--cpu-shares 옵션은 도커 컨테이너가 다른 컨테이너 대비 얼마 만큼이나 CPU를 사용할 수 있는 지를 가중치로 지정한다.

--cpus 옵션은 최대 x 개의 CPU를 사용할 수 있도록 하는 옵션이다.

--cpuset-cpus 옵션은 멀티 코어 시스템에서 특정 CPU를 사용하고 context-switch 비용을 낮추도록 한다.

외부 디바이스 접근 제어

호스트에 설치된 웹캠과 같은 디바이스를 컨테이너에 주입하여 사용할 수 있도록 한다.

docker container run -it --rm --device /dev/video0:/dev/video0 ubuntu:16.04 ls -al /dev

6.2 메모리 공유

프로세스 간 메모리를 공유(interprocess communication)하는 방법을 제공한다.

IPC를 사용하는 도커는 각 컨테이너마다 고유의 IPC 이름 공간을 생성한다. linux가 제공하는 IPC는 이름 공간으로 분리된 shared memory, 세마 포어, 메시지 큐와 같은 기본적인 공유 메모리를 제공한다.

docker container run -d -u nobody --name ch6_ipc_producer --ipc shareable dockerinaction/ch6_ipc -producer

docker container run -d -u nobody --name ch6_ipc_consumer --ipc container:ch6_ipc_producer dockerinaction/ch6_ipc -consumer

ch6_ipc_producer 컨테이너는 "shareable" 공유 가능한 ipc를 가진 컨테이너이다. (--ipc shareable)
ch6_ipc_consumer 컨테이너는 ch6_ipc_producer 컨테이너의 IPC를 조인하여 실행한다. (--ipc container:ch6_ipc_producer)
--ipc=host 옵션의 경우 호스트와 공유 가능하다.

참고: docker run | Docker Docs

6.3 Users

도커 컨테이너를 시작하면 이미지 메타데이터에 기록된 기본 유저를 사용한다. (주로 root 유저)

root 유저는 컨테이너 상태에 모든 접근 권한을 가진다.

이미지를 pull 한 이후 inspect 명령어를 사용하여 유저 이름을 확인할 수 있다.

docker image pull busybox:1.29
docker image inspect busybox:1.29
docker inspect --format "{{.Config.User}}" busybox:1.29

결과가 비어있다면, 컨테이너는 root 유저로 실행 중인 것이다. 그렇지 않다면, 이미지에 run-as 로 지정된 유저를 사용하거나 컨테이너를 생성할 때 지정한 유저가 출력된다.

linux는 미리 정의된 유저들을 사용한다. 다음과 같이 이미지에서 사용가능한 유저들을 알아 볼 수 있다.

docker contaienr run --rm busybox:1.29 awk -F: '$0=$1' /etc/passwd

위 리스트 중 유저를 선택하여 컨테이너를 시작한다면, 다음과 같이 -u 혹은 --user 옵션을 사용한다.

docker container run --rm --user nobody busybox:1.29 id

유저 이름을 지정하는 대신 UID를 직접 지정하여 유저를 설정할 수 있다.

docker container run --rm -u nobody:nogroup busybox:1.29 id
docker container run --rm -u 10000:20000 busybox:1.29 id

user:group 혹은 UID:GID, 유저와 그룹을 설정한다.

6.3.2 유저와 볼륨

볼륨으로 마운트한 파일에 호스트의 유저 중 하나로 소유자가 지정된 경우, 컨테이너에 지정된 유저가 접근이 허용되지 않을 수 있다.

root 유저 권한으로 지정한 파일을 컨테이너에 마운트 한 경우 같은 파일 권한을 가진다. 즉, root 유저가 아니라면 파일 접근이 허용되지 않게 된다.

6.3.3 linux user namespace와 UID remapping

linux의 user namespace(USR)는 유저를 한 이름 공간에서 다른 이름 공간의 유저로 맵핑한다. user namespace는 PID namspace 와 같이 컨테이너 UIDs와 GIDs는 호스트의 기본 개체들로 부터 할당된다.

도커는 USR namespace 기능을 기본값으로 사용하지 않는다. 그렇게 해야 호스트로 부터 마운트한 파일들 권한 유저를 컨테이너에서도 같은 유저 (UID)로 유지 할 수 있기 때문이다.

USR namespace 기능은 호스트 유저 중 권한을 상속받지 않은 유저를 컨테이너에서 사용하려 할 때 동작한다. 기능은 subuid와 subgid을 정의하고 usernamespace remapping을 한다. 그리고 도커 데몬 서비스의 userns-remap 설정을 구성한다. 맵핑은 호스트의 user namespace 에서 컨테이너의 user namspace 맵핑을 정의한다.

예를 들면 호스트의 5000 번 부터 시작하는 UID는 총 1000개의 UID 에 대해 컨테이너 내부에서는 0번 부터 1000번대까지로 맵핑한다.

6.4 OS 기능 사용하기 (capabilities)

host가 linux 일 경우 capabilties 기능은 컨테이너의 OS 기능을 선택적으로 상속한다.

컨테이너를 시작할 경우, 도커는 특별히 어플리케이션에 필요하여 명시적으로 지정하지 않은 경우를 제외 하고 모든 capabilites를 drop 한다.

drop 되는 capbilities는 다음과 같다.

SYS_MODULE - Insert/remove kernel modules

SYS_RAWIO Modify kerner memory

SYS_NICE Modify priorty of processes

SYS_RESOURCE override resource limits

...

추가로 capabilities를 drop 하고자하는 경우 --cap-drop 옵션을 지정하여 컨테이너를 실행한다.

docker container run --rm -u nobody \
--cap-drop net_raw ubuntu:16.04 /bin/bash -c "capsh --print | grep net_raw"

--cap-add 옵션은 반대로 capability를 컨테이너로 상속한다.

6.5 full previlege로 컨테이너 실행하기

시스템 관리자로서 컨테이너 내부에 작업을 수행해야할 때 유용하다. full previlege 컨테이너는 고립된 파일 시스템과 네트워크를 유지하지만 공유 메모리와 디바이스에 대한 전체 접근 권한과 system capabilites를 모두 획득한다.

docker container run --rm --priviledged ubuntu:16.04 id // check IDs
docker container run --rm --priviledged ubuntu:16.04 cpash --print  // check capabilities
docker container run --rm --priviledged ubuntu:16.04 ls /dev // check list of mounted devices

6.6 고급 도구로 컨테이너 사용하기

현대 linux 커널은 seccomp 도구를 제공하는데 강력한 시스템 보안 기능을 제공한다.

도커의 기본 seccomp는 40 개의 커널 시스템 콜을 사용하지 못 하게 한다. 또한 추가 도구를 사용하여 도커 컨테이너를 강화할 수 있다. 예를 들면, seccomp 프로필을 커스터마이즈 하거나 AppArmor, SELinux 와 같은 도구가 있다.

6.6.1 추가 보안 옵션 지정하기

--security-opt 플래그는 리눅스의 seccomp 와 Linux Security Modules (LSM) 기능을 구성한다.

Seccomp은 리눅스 시스템 콜을 제어한다. 도커의 기본 seccomp 프로필은 기본적으로 모든 시스템 콜을 차단하며 260개의 명시한 시스템 콜만 안전하다고 보고 허용한다. 44개의 시스템 콜은 보통 프로그램에서 호출되지 않게 한다.

seccomp 프로필을 설정하려면 다음과 같이 커스텀 프로필 파일을 제공한다.

docker contaienr run --rm -t --security-opt seccomp=<FULL_PATH_TO_PROFILE> ubuntu:16.04 sh

Linux Security Modules (LSM)는 프레임워크로 리눅스 OS와 보안 기능 공급자 사이의 인터페이스를 제공한다. AppArmor와 SELinux는 그러한 보안 기능 공급자 (security providers)이다. ACL이나 MAC 주소 검증 그리고 기본 리눅스 discrtionary access control을 대체하는 기능을 제공한다.

6.7 어플레케이션 고려 사항

해커에게 취약하지 않은 어플리케이션을 실행하고 운영하는 방법

- 제한된 권한을 가진 유저로 어플리케이션을 실행한다.

- system capabilites를 제한한다. 시스템 구성 설정이 보호될 것이다.

- CPU와 메모리 사용량을 제한한다. 호스트 머신의 필수적인 프로세스들의 높은 반응성을 유지시켜줄 것이다.

- 접근하는 디바이스를 제어한다. webcam, usb를 목적에 맞지 않은 사용을 방지하자.

요약

- 도커는 cgroup을 사용하여 메모리 제한과 CPU 가중치 할당, 제한, 코어 할당, 디바이스 접근 제어를 가능하게 한다.

- 각 컨테이너는 고유의 IPC 이름 공간을 가지며, 다른 컨테이너 혹은 호스트와 공유하여 공유 메모리를 접근할 수 있게 한다.

- 도커는 격리된 USR namespace를 사용한다. 기본적으로 호스트와 같은 user, group ID를 사용하지만 호스트에 있지 않은 컨테이너의 user, group ID는 호스트로 부터 재맵핑된다.

- --user 옵션으로 root 유저가 아닌 컨테이너를 실행할 유저를 지정할 수 있다.

- previledge 모드 관리자 작업을 가능하게 한다 가능하다면 previledge 모드로 컨테이너를 실행하지 말자.

- linux capabilites는 OS 기능 권한을 제공한다. 도커는 격리의 이유로 몇몇 capabilites를 호스트로부터 상속하지 않는다.

- capbilites 상속 혹은 제거는 --cap-add 또는 --cap-drop으로 가능하다.

- 더 격리된 환경을 제공하고 높은 보안 수준을 위해 seccomp, SELinux, AppArmor와 같은 도구를 같이 사용하여 컨테이너 실행하는 것을 고려하라.

[C++] Memory Pool

로파이 — Sun, 31 Mar 2024 00:15:21 +0900

메모리 풀 구현

32/64/128/... 바이트 단위로 메모리를 미리 할당하여, 실제 할당할 때 해당 메모리를 사용함.

장점
메모리 단편화 문제를 완화 가능. 특히 사이즈가 큰 메모리를 할당할 때 적절한 위치의 페이지를 찾는 것이 시간이 소요될 수 있다.

단점
사용하지 않는 메모리를 미리 할당하여 사용하게 되는 낭비.
메모리 풀과 같이 특정 할당자(Allocator)를 사용한 경우, 메모리를 반납하여 재사용할 수 있도록 할당자를 통한 해제를 해야한다.

std::shared_ptr의 생성자에는 해제자 deleter에 대한 인스턴스를 받아 해제를 제어할 수 있다.

std::unique_ptr는 타입으로 선언하여 사용한다. 커스텀 deleter를 사용하는 경우 타입 이름이 지저분해질 수 있다.

MemoryHeader

#pragma pack(push, 1)
struct DECLSPEC_ALIGN(MEMORY_ALLOCATION_ALIGNMENT) MemoryHeader {
	SLIST_ENTRY* next;
	struct Info {
		size_t id : 16;
		size_t size : 16;
		size_t tag : 32;
	} info;
	static constexpr size_t kSize = sizeof(SLIST_ENTRY*) + sizeof(Info);
};
#pragma pack(pop)

각 메모리의 헤더 부분으로 기본 16바이트를 차지하게 된다.
SLIST_ENTRY* next 부분은 windows의 InterlocekdSList를 사용하기 위한 필드.

*InterlockedSList는 lock-free FIFO 자료구조 API를 제공한다.
Interlockedapi.h header - Win32 apps | Microsoft Learn

Interlockedapi.h header - Win32 apps

Table of contents Article 01/24/2023 Feedback In this article --> This header is used by System Services. For more information, see: interlockedapi.h contains the following programming interfaces: Functions InitializeSListHead Initializes the head of a

learn.microsoft.com

StaticMemoryPool
필요한 페이지를 미리 할당하여 Memory 사이즈 단위로 미리 잘라서 쓰는 방식

class StaticMemoryPool {
public:
	struct BlockAlloc {
		size_t size;
		size_t count;
	};

	static constexpr size_t kMaxBlockSize = 0x4000;
    //...

	StaticMemoryPool(size_t block_size, size_t target_block_num)
		:
		_block_size(block_size) {
		_address_begin = MemoryManager::Get().request(nullptr, _block_size, target_block_num, _alloc_size);
		_address_end = reinterpret_cast<char*>(_address_begin) + _alloc_size;
		_alloc_count = _alloc_size / _block_size;
		for (size_t i = 0; i < _alloc_count; ++i) {
			auto* header = reinterpret_cast<MemoryHeader*>(reinterpret_cast<char*>(_address_begin) + i * _block_size);
			header->next = nullptr;
			header->info.tag = kFreeTag;
			header->info.id = 0;
			header->info.size = 0;
			_free_list.push(header);
		}
	}

   //...
};

예를 들면, 32바이트 단위의 메모리를 연속된 주소로 1024개를 할당하여 미리 가지고 있는다.
각 32바이트의 첫 16바이트는 메모리 헤더로 사용하고 초기화시 SList 인스턴스인 _free_list에 넣어둔다.

allocate 및 dellocate

	void* allocate(size_t size) noexcept {
		auto header = _free_list.pop();
		if (header == nullptr) {
			return ::malloc(size);
		}
#ifdef _DEBUG
		assert(header->info.tag == kFreeTag);
		header->info.tag = kAllocTag;
		header->info.id = _id_counter.fetch_add(1, std::memory_order_relaxed);
		header->info.size = size;
#endif // !_DEBUG
		return reinterpret_cast<char*>(header) + MemoryHeader::kSize;
	}

	void  deallocate(void* ptr, size_t size) noexcept {
		if (contains(ptr) == false) {
			::free(ptr);
			return;
		}
		auto* header = reinterpret_cast<MemoryHeader*>(reinterpret_cast<char*>(ptr) - MemoryHeader::kSize);
#ifdef _DEBUG
		assert(header->info.tag == kAllocTag);
		header->info.tag = kFreeTag;
#endif // !_DEBUG
		_free_list.push(header);
	}

size 만큼 할당 요청에 대하여 _free_list로 부터 여분의 메모리가 있으면 해당 메모리를 반환한다.
여분이 없다면 malloc을 사용하여 기본 내장 할당 함수를 사용한다.

해제 시 해당 메모리 주소를 기준으로 자신이 관리하는 메모리 주소 영역을 판단하여 다시 반납하거나 아니라면 free 함수를 통해 직접 해제한다.

std::allocator_traits

std 컨테이너를 정의할 때 흔히 원소에 대한 첫 타입 외 Allocator 타입을 받을 수 있는데
커스텀 할당자를 정의하여 컨테이너 원소를 할당할 때 사용할 수 있다.

이 때 커스텀 할당자는 std::allocator_traits 제약을 만족해야한다.
- 참고
https://en.cppreference.com/w/cpp/memory/allocator_traits

https://learn.microsoft.com/ko-kr/cpp/standard-library/allocator-traits-class?view=msvc-170

- 예시
MemoryPool을 사용하는 StaticAllocator

template<typename T>
class StaticAllocator {
public:
	using allocator_type = StaticAllocator<T>;
	using value_type = T;
	using size_type = size_t;
	using difference_type = ptrdiff_t;
	using pointer = T*;
	using const_pointer = const T*;
	using reference = T&;
	using const_reference = const T&;

	StaticAllocator() = default;
	~StaticAllocator() = default;

	StaticAllocator(const StaticAllocator&) noexcept {};
	StaticAllocator& operator=(const StaticAllocator&) noexcept { return *this; }

	template<typename U>
	StaticAllocator(const StaticAllocator<U>&) noexcept {}
	template<typename U>
	StaticAllocator& operator=(const StaticAllocator<U>&) noexcept { return *this; }

	constexpr pointer address(reference x) const noexcept { return &x; }
	constexpr const_pointer address(const_reference x) const noexcept { return &x; }

	pointer allocate(size_type n, const void* = 0) {
		size_t alloc_size = n * sizeof(T);
		if (alloc_size > StaticMemoryPool::kMaxAllocSize) {
			return static_cast<pointer>(::malloc(alloc_size));
		}
		return static_cast<pointer>(StaticMemoryPool::g_memory_mapper.Get(alloc_size).allocate(alloc_size));
	}

	void deallocate(pointer p, size_type n) {
		size_t alloc_size = n * sizeof(T);
		if (alloc_size > StaticMemoryPool::kMaxAllocSize) {
			return ::free(p);
		}
		StaticMemoryPool::g_memory_mapper.Get(alloc_size).deallocate(p, alloc_size);
	}

	template<typename ...Args>
	void construct(pointer p, Args&&... args) {
		new (p) T(std::forward<Args>(args)...);
	}

	void destroy(pointer p) {
		p->~T();
	}
};

- allocate(size_type, const void* hint)
n 개의 초기화 되지 않은 메모리를 할당한다. 이전 할당 주소 등을 가리켜 hint는 할당하고자하는 메모리 주소에 대한 힌트를 제공한다.

배열과 같이 한 번에 여러 개를 요청할 때만 n > 1이다.

- deallocate(pointer p, size_type n)
p 주소에 대한 메모리를 해제한다.

- construct
new 연산자와 같이 할당된 메모리에 대한 주소에 초기화 작업을 수행한다.

- destroy
개체 파괴를 진행하여 메모리를 해제하기 전에 소멸자와 같이 정리 작업을 수행한다.

위 allocator 타입을 사용하여 shared_ptr 인스턴스를 생성하는 예시

struct SharedPtrFactory {
	template<typename T, template <typename...> typename Allocator = std::allocator, typename ...Args>
	static inline std::shared_ptr<T> Execute(Args&&... args) {
		Allocator<T> allocator;
		return std::allocate_shared<T>(allocator, std::forward<Args>(args)...);
	}
};

테스트
std::allocator, std::pmr::polymorphic_allocator, StaticAllocator, DynamicAllocator (요청할 때 메모리를 할당하여 재사용)
백만번의 컨테이너 요소 삽입과 삭제에서 더 빠른 성능을 보인다.
특정 사이즈의 메모리를 많이 사용할 것을 미리 알 수 있다면, 더 많은 메모리를 미리 할당하여 사용할 때 유리하다.

테스트 코드

Allocator.zip

0.01MB