LaMelD

알고리즘 풀이 저장소 정리

Mon, 14 Sep 2026 00:00:00 +0000

흩어져 있던 풀이 저장소(Cpp-Solution, Python-Solution, programmers)를 algorithms 하나로 합쳤다. 커밋 이력은 그대로 남겼고, 구조만 언어별로 정리했다.

RP-CHAT: 캐릭터와 1:1로 대화하는 RP 챗봇

Fri, 29 May 2026 00:00:00 +0000

미리 정의된 캐릭터와 1:1로 대화하는 학습용 챗봇이다. 응답은 소설 대본처럼 지문(이탤릭) + 대사(굵게, 큰따옴표) 형식으로 스트리밍된다. 처음에는 도구 호출을 하는 ReAct 어시스턴트로 시작했다가, 캐릭터 일관성을 우선하기로 하고 캐릭터 RP 전용으로 방향을 바꿨다.

메모리 스토리지 엔진

Sun, 09 Apr 2023 00:00:00 +0000

특징

메모리 스토리지 엔진을 사용하는 테이블의 데이터는 디스크를 사용하지 않고 메모리 내에만 저장되고 엑세스 된다.

1장 쉘 스크립트 개요

Wed, 15 Jul 2020 00:00:00 +0000

1.1 UNIX/Linux 소개 및 특징

1.1.1 UNIX
- 1969년 AT&T 벨연구소의 직원이 켄 톰슨, 데니스 리치, 더글라스 매클로리 등이 최초로 개발하였으며, 이후 C언어로 재작성되어 다양한 플랫폼에 이식될 수 있도록 보완되었다.
- 벨연구소는 대학과 연구기관에 UNIX를 활용할 수 있도록 라이선스를 제공하였으며, 버클리 대학교에서는 UNIX에 네트워크 프로토콜인 TCP/IP 등 다양한 기능을 보강하여 BSD 배포본을 제작하고 이후 파생되는 많은 UNIX에 영향을 끼쳤다.
1.1.2 Linux
- 1991년 리누스 토발즈라는 핀란드 헬싱키 대학의 대학원생에 의해 커널이 개발된 이래, 1984년부터 리처드 스토람에 의해 추진된 GNU 프로젝트의 다양한 소프트웨어들이 합쳐진 운영체제가 Linux이다.
- 개인용 데스크톱 환경뿐만 아니라 안드로이드 등 스마트폼에서부터 기업용 엔터프라이즈 환경에 이르기까지 다양한 플랫폼에 이식되어 활용중이다.
- 대표적인 리눅스 배포판에는 데비안, 레드햇, 슬렉웨어, SUSE, 우분투, 젠투가 있으며 그밖에도 다양한 배포본들이 파생되어 개발되고 있다.

1.2 쉘의 역할 및 특징

쉘은 운영체제에서 커널(Kernel)과 사용자 사이의 인터페이스, 즉 가교 역할을 하는 프로그램으로, 운영체제의 내부 명령어나 응용프로그램을 실행하는 것을 지원한다.
시스템을 전체적으로 보면 운영체제는 결국 하드웨어의 한 부분인 저장장치의 일부에 저장된다.
운영체제를 좀 더 세부적으로 살펴보면, 운영체제가 설치되어 있는 저장장치(DISK 등)를 비롯하여 모니터, 그래픽카드, NIC 등 시스템에 직간접적으로 연결되는 하드웨어를 통제하는 커널과 이러한 커널과 사용자 및 응용 프로그램 사이에서의 명령을 전달을 담당하는 쉘로 구분할 수 있다.
운영체제 마다 기본적으로 다양한 쉘을 제공하고 있고 사용자가 별도의 쉘을 설치해서 활용할 수 있다.
CDE(Common Desktop Environment)
- 공통 데스크톱 환경(CDE)은 유닉스를 위한 그래픽 데스크톱 환경이며 모티프 위젯 툴킷을 도입하고 있다.
- 유닉스 표준화 단체들 가운데 하나인 공통 개방형 소프트웨어 환경이 지정한 유닉스 GUI 규격이다.

1.3 쉘의 종류

구분	개발자	설치 위치	설명
sh	Stephen Bouren	/bin/sh	대부분의 UNIX 및 Linux에 설치되어 있는 쉘
bash	Brain Fox, Chet Ramey	/bin/bash	Linux의 기본 쉘로 sh와 호환
ksh	David Korn	/bin/ksh	1980년대 벨연구서에서 개발, 부동 소수점 계산이 가능
csh	Bill Joy	/bin/csh	C언어와 비슷한 스타일로 Script를 작성 가능
tcsh	Ken Greer	/bin/tcsh	csh에 커맨드 히스토리 등 추가 기능을 보완

쉘 종류의 확인
```
$ ps -p $$
```
/etc/passwd 파일의 내용 중 마지막 필드에 기술된 쉘 경로를 보고 확인할 수 있다.
```
user01:x:500:500::/home/user01:/bin/bash
```
시스템에 항상 자신이 원하는 쉘이 설치되어 있을 거라고 생각하면 안된다.
대부분의 UNIX/Linux 시스템에 기본적으로 설치되어 있는 sh를 중심으로 설명할 것이다.

1.4 쉘 스크립트란?

컴퓨터 사용의 편의성을 확보한 GUI 기반의 실행 환경인 Windows 초기 버전이 있었지만 DOS를 통해 구동되는 DOS의 확장 프로그램 수준이었기 때문에 일반 사용자가 쉽게 사용하기에는 어려움이 있었다.
이러한 번거로움을 조금이나마 해소하고자 DOS 구성 시 메모리 구성 및 드라이버 로딩을 케이스별로 메뉴로 구성하여 케이스별로 선택할 수 있는 배치 파일을 만들어 활용하는 사람들이 있었다.
그 당시의 배치 파일을 지금의 쉘 스크립트와 비슷한 개념으로 이해하면 된다.
쉘 스크립트 : 운영체제의 쉘에서 사용할 수 있는 명령어를 해석하고 그 결과를 커널에게 전달하는 프로그램
쉘 : 사용자가 내린 명령어를 해석하고 그 결과를 커널에게 전달하는 프로그램

1.5 쉘 스크립트 활용 시 이점

1.5.1 반복 작업에 대한 자동화 기능
- 쉘 스크립트를 활용하는 가장 큰 장점은 관리자의 번거로움을 덜 수 있다.
- 스케줄 설정과 같이 주기적으로 수행하는 단순한 작업에 단순한 작업에 쉘 스크립트를 활용하면 관리자가 일일이 타이핑하지 않아도 된다.
1.5.2 기존의 명령어를 사용자만의 명령어로 보완
- 기본적으로 UNIX/Linux는 POSIX라는 표준 규약을 준수하지만 모든 명령어가 통일된 것은 아니기 때문에 운영체제 마다 명령 옵션이나 결과 형식에 약간의 차이가 있다.
- 운영체제에서 제공하는 명령어 실행 결과를 사용자가 원하는 형식으로 재구성해야 할 때가 있다.
- 예시
  - 운영체제가 다른 시스템에서 동일한 형태의 로그를 추출해야 할 때가 있다.
  - 이 경우, 쉘 스크립트를 이용하여 기존의 명령어의 결과를 원하는 형태의 결과로 표시할 수 있다.
  - 이를 위해 입출력 재지정(Rdirection)을 활용하면 된다.
1.5.3 손쉽고 빠른 개발 및 보완이 가능
- 기본적으로, 쉘 스크립트 자체는 운영체제의 명령어 등을 묶어서 프로그램화한 후 인터프리터 방식으로 수행되기 때문에 별도의 컴파일러를 설치할 필요가 없다.
- 운영체제의 명령어들을 잘 알고 있다면 손쉽고 빠른 개발 및 보완이 가능하다.
- 필요한 절차를 기술하는 것이다.
- 시스템 관리자가 관리하는 여러 대의 서버 및 원격지에 있는 서버를 설정하거나 패치할 때 쉘 스크립트를 활용하면 설정 및 패치 작업을 보다 더 효율적으로 할 수 있다.
POSIX(Portable Operating System Interface)
- 서로 다른 UNIX OS의 공통 API를 정리하여 이식성이 높은 유닉스 응용 프로그램을 개발하기 위한 목적으로 IEEE가 책정한 어플리케이션 인터페이스 규격이다.
- 대부분의 시스템들이 AT&T에서 개발된 UNIX에 뿌리를 두고 있지만 시간이 흐르면서 다양한 제조사와 개발자의 손을 거치면서 운영체제별 의존성 문제가 발생되었다.
- POSIX는 운영체제별 의존성 문제를 해결하기 위해 서로 다른 UNIX 운영체제에서 공통 API를 정리하여 운영체제간 이식성이 높은 UNIX 응용 프로그램을 개발하기 위한 목적으로 제정된 API 규격이다.

1-1 : AWS란?

Mon, 13 Jul 2020 00:00:00 +0000

AWS란?

Amazon Web Service는 Amazon에서 제공하는 클라우드 서비스이다.
네트워크 기반으로 가상 컴퓨터와 스토리지를 비롯한 다양한 서비스를 제공하고 있다.
2004년 Amazon Simple Queue Service(SQS)부터 시작되었다.
2006년 온라인 스토리지 서비스(S3)와 가상 컴퓨터 서비스(EC2)부터 AWS가 본격적으로 시작되었다.

클라우드란?

클라우드 컴퓨팅 : 컴퓨터 리소스의 이용 형태
클라우드는 컴퓨터의 계산 리소스, 스토리지 영역, 어플리케이션 처리를 네트워크 기반 서비스로 제공한다.
인프라스트럭처 서비스(Infrastructure as a Service : IaaS)
- 가상 서버 또는 스토리지 등의 리소스를 인터넷을 기반으로 제공하는 서비스를 의미한다.
- 사용자는 물리적인 하드웨어를 관리할 필요가 없으며, 직접적으로 컴퓨터 리소스를 사용할 수 있다.
- 가장 아래의 기초적이 부분을 담당한다.
- 물리 장치에 가장 가까운 서비스라고 할 수 있다.
플랫폼 서비스(Platform as a Service : PaaS)
- 데이터베이스 또는 어플리케이션 서버 등의 미들웨어를 제공하는 서비스
- OS와 미들웨어의 관리는 제공자가 한다.
- 사용자는 미들웨어만을 직접 사용할 수 있다.
어플리케이션 서비스(Software as a Service : SaaS)
- 소프트웨어 또는 어플리케이션의 기능을 인터넷을 통해 제공한다.
- SaaS를 제공하는 것을 SaaS 제공자(Provider)라고 한다. 이는 ASP(Application Service Provider)와 거의 같은 것이다.
- ASP라는 형태의 서비스 제공은 클라우드 이전부터 있었지만 SaaS 제공자는 클라우드라는 것에 조금 더 비중을 두어 말하는 것이라고 생각하면 된다.

물리 서버(On Premise)와 AWS의 차이

물리 서버 : 조직 내부에서 사용할 목적으로 준비한 설비

CH01. 도커의 기본

Wed, 01 Jul 2020 00:00:00 +0000

1. 도커란 무엇인가?

도커
- 컨테이너형 가상화 기술을 구현하기 위해 상주 어플리케이션과 이 어플리케이션을 조작하기 위한 명령행 도구로 구성되는 프로덕트다.
- 어플리케이션 배포에 특화되어 있기 때문에 어플리케이션 개발 및 운영을 컨테이너 중심으로 할 수 있다.
도커의 역사

md2html: 마크다운을 저장하면 HTML이 따라 생기는 Claude Code 플러그인

Tue, 26 May 2026 00:00:00 +0000

저장소: github.com/LaMelD/md2html

.md 파일을 작성하거나 수정할 때마다 같은 디렉토리에 .html이 자동으로 생기는 Claude Code 플러그인이다. 산출물은 두 개다.

시퀀스 스토리지 엔진

Sun, 09 Apr 2023 00:00:00 +0000

특징

단순히 순차적인 번호를 주어진 조건에 맞게 생성만 해주는 스토리지 엔진

2장 실습 환경 구축

Mon, 03 Aug 2020 00:00:00 +0000

2.1 UNIX/Linux 시스템 구축

2.1.1 가상머신 설치
- x86에 설치되지 않는 UNIX/Linux 버전은 사용이 불가능하다.(IMB의 AIX, HP의 HP-UX, SUN의 SPARC CPU 버전 Solaris 등)
- VMware 또는 VirtualBox 설치
2.1.2 게스트 운영체제 설치

1-2 : AWS의 네트워크 서비스

Mon, 13 Jul 2020 00:00:00 +0000

네트워크는 AWS의 서비스를 지탱하는 가장 중요한 인프라라고 할 수 있다.

CH02. 도커 컨테이너 배포

Wed, 01 Jul 2020 00:00:00 +0000

1. 컨테이너로 어플리케이션 실행하기

도커 이미지 : 도커 컨테이너를 구성하는 파일 시스템과 실행할 어플리케이션 설정을 하나로 합친 것으로 컨테이너를 생성하는 템플릿 역할을 한다.

백준 풀이 목록

Sun, 29 Mar 2020 00:00:00 +0000

algorithms/cpp/Beakjoon에 있는 백준 C++ 풀이 112문제의 목록이다. 번호를 누르면 백준 문제 페이지로, 코드를 누르면 풀이 파일로 간다.

Network

Tue, 31 Dec 2019 13:23:21 +0900

191230 Monday ~ 200103 Friday

1. 기본적으로 알아야 할 컴퓨터 기초

데이터 표현
- 2진법, 10진법, 16진법(0x00)
HW 구성요소
- CPU(central processing unit)
  - processor : 물리적 코어
- RAM(memory : random access memory) : 주 기억
  - process : 실행되고 있는 프로그램
- 하드 디스크(SSD/HDD) : 보조 기억
- I/O 장치
운영 체제(OS : operating system)
- 하드웨어를 관리해주는 프로그램
- 구성요소 : 커널, 쉘, 응용 프로그램
파일의 특징
- 파일의 이름(확장자)
  - exe, txt, zip, egg, etc. -> 4D 5A -> 윈도우에서 실행파일 일 경우 binary의 시작
- 파일의 경로
  - 다양하게 지정할 수 있는 파일의 경로

2. VMware(workstation) : 가상화에 관련된 회사 이름

정의
- 하이퍼바이저 기반 가상 머신 소프트웨어
하이퍼바이저
- 가상 머신을 만들어주는 프로그램
- HOST에서 GUEST를 만들어주는 프로그램
- 현재 사용하려는 workstation이 하이퍼바이저
실습
- vmware 설치
- 가상 머신 생성

3. 네트워크

정의
- 노드들이 데이터를 공유할 수 있게 하는 디지털 전기 통신망의 하나이다.
- 분산되어 있는 컴퓨터를 통신망으로 연결한 것을 말한다.
- 네트워크에서 여러 장치들은 노드 간 연결을 사용하여 서로에게 데이터를 교환한다.
- *노드 : 네트워크에 속한 컴퓨터 또는 통신 장비
- 네트워크? 인터넷? www?
  가장 큰 네트워크 인터넷
  www : world wide WEB
분류
- 크기에 따른 분류
  - LAN, WAN, MAN, 기타
  - LAN : 가까운 지역을 하나로
  - WAN : 멀리 있는 지역을 하나로
- 연결 형태에 따른 분류
  - Star 형 : 중앙 장비에 모든 노드가 연결된 형태
  - Mesh 형 : 여러 노드들이 서로 그물처럼 연결된 형태
  - 혼합형(Star + Mesh)
통신 방식
- 유니 캐스트 : 1:1 통신
- 멀티 캐스트 : 1:다수 통신
- 브로드 캐스트 : 같은 네트워크(Local)에 있는 모든 대상에게 통신
프로토콜
- 정의 : 일종의 양식, 네트워크에서 노드와 노드가 통신할 때 어떤 노드가 어느 노드에게 어떤 데이터를 보내는지 작성하기위한 양식
- 가까운 곳으로 통신 : Ethernet 프로토콜(MAC 주소)
- 멀리 있는 곳으로 통신 : ICMP, IPv4, ARP(IP 주소)
- 여러가지 프로그램으로 통신 : TCP, UDP(port 번호)
- 여러 프로토콜들로 캡슐화 된 패킷(Ethernet/IPv4/TCP/데이터)
실습
- tracert [ip or address] : 네트워크 경로 추적
  네트워크 장비 30개 이하로 연결되어 있다(30홉 이하)
- wireshark : 네트워크 패킷을 볼 수 있다.

4. 네트워크 모델

[D4] 2819

Fri, 29 Nov 2019 17:38:30 +0900

격자판의 숫자 이어 붙이기

문제 출처

문제 설명
1. 4 x 4 크기의 격자판이 있다. 격자판의 각 격자칸에는 0부터 9사이의 숫자가 적혀 있다.
2. 격자판의 임의의 위치에서 시작한다.
3. 동서남북 네 방향으로 인접한 격자로 총 6회 이동하여 각 칸에 숫자를 차례로 이어 붙인다.
4. 이동을 할 때 중복을 허용한다.
5. 0으로 시작하는 수도 만들 수 있다.
6. 가능한 7자리 숫자의 개수를 구한다.
문제 풀이

1. 파이썬 프로그래밍의 기초, 자료형

Fri, 29 Nov 2019 17:38:30 +0900

1. 숫자형

숫자 형태로 이루어진 자료형
정수, 실수, 복소수, 8진수, 16진수 등
숫자형을 활용하기 위한 연산자
- 더하기, 빼기, 곱하기, 나누기, 나머지 연산
- 제곱을 나타내는 연산자 : a**b
- 나눗셈 후 소수점 아랫자리를 버리는 연산자 : 7//4

2. 문자열 자료형

문자, 단어 등으로 구성된 문자들의 집합

1장 : 깃 시작하기

Fri, 29 Nov 2019 17:38:30 +0900

1. 깃으로 무엇을 할 수 있을까?

버전관리
- local 저장소에 관련된 내용 :: git
백업하기
- remote 저장소에 관련된 내용 :: github
협업하기
- git, github 다루기

2. 깃 설치하기

기본적인 설치
- 깃 설치 사이트에서 설치할 수 있다.
- 설치과정은 기본적으로 설정되어있는 것을 따라간다.
- 설치가 완료되면 윈도우 작업 표시줄의 검색 창에 git이라고 입력한 후 검색 결과 중에서 Git Bash를 누른다.
- git이라고 입력한 수 enter를 눌러보면 깃 명령에서 사용할 수 있는 여러 옵션이 표시된다면 설치 성공이다.
깃 환경 설정
- 사용자 설정을 위해 git config 명령을 사용합니다. 여기서 –global 옵션은 현재 컴퓨터에 있는 모든 저장소에서 같은 사용자 정보를 사용하도록 설정한다.
```
$ git config --global user.name "사용자 이름"
$ git config --global user.email 사용자@이메.일
```

3. 리눅스 명령 연습

~ : 홈 디렉토리
pwd : 현재 작업 디렉토리
ls : 디렉토리 내용 확인
cd : 디렉토리 이동
. : 현재 디렉토리
.. : 상위 디렉토리
mkdir : 디렉토리 생성
rm : 파일 제거
- rm -rf : 파일, 디렉토리를 가리지 않고 삭제(-r : recursive, -f : force)
vim : 편집기
- 기본 편집기 변경하기
- git config -- global core.editor "notepad++"
touch : 빈 파일 생성
cat : 파일 내용 확인
- cat [파일이름]
- cat [파일1], [파일2], [파일3], ... , [파일n] > [새파일] : 파일n 개를 차례로 연결해서 새로운 파일을 만든다.
- cat [파일1] >> [파일2] : 파일1의 내용을 파일2 끝에 연결한다.

[2018] 캐시

Fri, 22 Nov 2019 00:00:00 +0000

문제 출처

문제 설명
1. 캐시 교체 알고리즘은 LRU(Least Recently Used) 를 사용한다.
2. cache hit 일 경우 실행시간은 1이다.
3. cache miss 일 경우 실행시간은 5이다.
4. 총 실행 시간을 출력한다.
문제 풀이

[DS] Array

Fri, 15 Nov 2019 00:00:00 +0000

Array(배열)

정적 배열 (Static Array)
- 기본적인 배열을 의미한다.
- C++에서 간단하게 선언이 가능하다.
1차원

컨넥트 스토리지 엔진

Sun, 09 Apr 2023 00:00:00 +0000

특징

기능을 제공하는 스토리지 엔진
다른 서버의 mariaDB 테이블과 연결
이기종 RDBMS의 테이블과 연결

3장 UNIX/Linux 기본 명령어와 개념

Tue, 21 Jul 2020 00:00:00 +0000

기본 리눅스 명령어가 익숙한 독자는 4장으로 가서 쉘 스크립트 작성에 관련된 기본 문법을 숙달하는 것을 추천한다.

1-3 : 하드웨어 리소스

Tue, 14 Jul 2020 00:00:00 +0000

Amazon Elastic Compute Cloud(EC2)

EC2
- 클라우드 위에서 가상 서버(인스턴스), 백업 이미지(AMI, 스냅샷), 디스크(EBS), 방화벽(보안 그룹), 고정 글로벌 IP(Elastic IP) 등을 사용할 수 있게 해주는 서비스
- 기본적인 사용 방법은 AWS가 제공하는 AMI를 기반으로 디스크 용량 또는 통신 요건을 설정해서 인스턴스를 생성하는 것이다.
- 인스턴스에 로그인해서 미들웨어 설치 또는 설정을 할 수 있으며, 백업이 필요한 시점에 AMI를 생성하거나, 필요에 따라 Elastic IP를 부여해서 인터넷과 통신할 수 있다.
인스턴스
- 기존의 On Premise 환경 위의 서버에 해당한다.
- 인스턴스가 갖는 정보 : OS, CPU, 메모리
- 실제로 설치할 미들웨어 또는 저장할 데이터는 EBS에 저장된다.
선택할 수 있는 OS의 종류
- RedHat Enterprise Linux
- SUSE Linux Enterprise Server
- Ubuntu
- Fedora
- Debian
- CentOS
- Gentoo Linux
- Oracle Linux
- FreeBSD
- Windows Server
인스턴스에 적용할 수 있는 인스턴스 유형
- 인스턴스 유형이란 인스턴스에 적용할 CPU, 메모리, 내장 디스트, 네트워크 용량 패턴을 나타낸다.
- 사용 목정에 따라 구분된다.
  - 범용 T2 인스턴스와 M3 인스턴스
  - CPU 성능을 높게 설정한 C3 인스턴스와 C4 인스턴스
  - 메모리 용량을 크게 설정한 R3 인스턴스
인스턴스 스토리지
- EC3 인스턴스가 가동되는 물리 서버에 있는 로컬 디스크를 나타낸다.
- 인스턴스 유형에 따라 사용할 수 있는 인스턴스 스토리지의 크기와 개수가 정해진다.
- 인스턴스 스토리지를 사용할 때 주의해야 하는 것은 인스턴스 스토리지에 있는 데이터는 EC2 인스턴스를 중지하면 사라진다는 것이다.
EBS-Backed 인스턴스와 Instance Store-Backed 인스턴스
- EBS-Backed 인스턴스
  - OS를 포함한 루트 디바이스 정보를 EBS에 저장한 인스턴스를 나타낸다.
  - AWS는 EBS-Backed 인스턴스를 권장하고 있다.
  - EC2 인스턴스의 가동 중인 루트 장치와 관련된 변경 사항이 모두 EBS에 기록되므로, 인스턴스를 정지해도 변경 사항이 유지된다.
  - 변경 내용이 반영된 상태로 인스턴스를 기동할 수 있다.
- Instance Store-Backed 인스턴스
  - OS를 포함한 루트 디바이스 정보를 S3에 저장한 인스턴스를 나타낸다.
  - 인스턴스 기동 때는 S3에서 인스턴스 스토리지에 데이터를 복사하고 기동한다.
  - 이후에 다시 기동하면 S3에서 루트 디바이스를 처음부터 읽어 들이므로, 이전 변경 사항은 모두 파기된다.
  - 루트 장치의 내용을 변경하고 싶다면 전용 도구를 사용해서 변경 후의 내용을 S3에 업로드해야 한다.
인스턴스 비용
- 인스턴스 유형에 따른 가격과 시간을 곱하면 구할 수 있다.
- 예시
  - r2.small 인스턴스를 10일 동안 사용하면 다음과 같이 계산한다.
  - $0.04/시간 * 24시간 * 10일 = $9.6
- 인스턴스가 1시간을 넘지 않는 시간만큼 가동해도 1시간 만큼의 비용이 발생한다.
인스턴스 비용 최적화
- 인스턴스의 활용 목적을 분명하게 해서 인스턴스 유형과 가동 시간을 조절해야 한다.
- 인스턴스를 지정한 날짜에 가동해서 처리하는 것은 AWS가 제공하는 CLI 또는 API를 활용해 쉽게 자동화할 수 있다.
EC2 인스턴스에서 사용하는 OS 라이선스
- OS 라이선스 비용은 EC2 사용 비용에 포함되어 있다.
- 선택한 OS에 따라서 같은 인스턴스 유형이라도 시간당 비용이 다를 수 있다.

Amazon Elastic Block Store(EBS)

EBS 볼륨 유형
- 범용(SSD)
  - 1GB마다 3IOPS의 베이스 퍼포먼스를 가진다.
  - IOPS를 직접적으로 지정할 수는 없지만, 용량이 늘어나면 자동으로 IOPS도 올라간다.
  - 스토리지에 대한 읽고 쓰기는 비용이 추가되지 않는다.
- 프로비저닝된 IOPS(SSD)
  - 최대 4000IOPS까지 I/O 성능을 지정할 수 있다.
  - 굉장히 빈번하게 I/O가 지속적으로 발생할 때 프로비저닝된 IOPS를 사용한다.
- 마그네틱
  - 기존의 마그네틱 디스크에 해당한다.
  - AWS가 SSD를 지원하기 시작한 이후로는 권장하지 않고 있다.
  - SSD에 비교해서 스토리지 비용이 싸므로, 개발 환경 등에 조금만 활용하는 경우에 적합하다.
  - 읽고 쓰는 것에 대해서 비용일 발생하므로 주의가 필요하다.
EBS 비용
- 인스턴스 유형에 따른 가격, 용량, 시간을 곱하면 구할 수 있다.
- 예시
  - 서울 리전에서 범용(SSD)을 10GB만큼 10일 사용하면 다음과 같이 계산한다.
  - $0.12/(1GB/월) * 10GB / 30일(1개월) * 10일 = $0.4
EBS 크기 변경
- EBS의 크기를 변경하려면 이후에 설명하는 EBS 스냅샷을 생성해야한다.
- 생성한 EBS 스냅샷을 기반으로 EBS를 복구하게 만들고, 이때 크기를 변경해서 저장하면 된다.
- EBS 크기를 변경할 때 용량 크기를 늘릴 수 있지만, 감소시킬 수 없다는 것에 주의가 필요하다.
EBS 암호화
- EBS를 새로 생성할 때 암호화 옵션을 활성화할 수 있다.
- 암호화 방식은 AWS가 관리하는 암호 키(SSE-S3)를 활용한 AES-256 알고리즘을 사용하고 있다.
- 암호화 옵션을 활성화한 EBS는 인스턴스에 Attach하면, 읽고 쓰는 데이터들을 암호화하게 된다.
- 암호화 옵션을 사용한 EBS를 기반으로 만든 스냅샷(백업 기능)을 기반으로 복구하면 자동적으로 암호화 옵션이 활성화되며, 원래 EBS와 같은 키로 암호화 된다.
- 주의 사항
  - 암호화 옵션을 활성화하지 않고 만든 EBS는 이후에 암호화 옵션을 활성화할 수 없음
  - 암호화 옵션을 활성화한 스냅샷은 다른 AWS 계정과 공유할 수 없음
  - 암호화 옵션을 사용하는 인스턴스 유형에만 사용할 수 있음
EC2, EBS의 SLA
- EC2, EBS는 2013년 6월에 SLA(Service Level Agreement : 품질 서비스)를 발표했다.
- 관련 디테일

EC2 백업

EC2 백업
- EC2 인스턴스 또는 EBS를 운용할 때 빼놓을 수 없는 것은 AMI와 EBS 스냅샷이라는 백업이다.
- 인스턴스 또는 EBS로부터 AMI, EBS 스냅샷을 생성하면, 언제든지 해당 시점으로 복구할 수 있다.
- 리전 간의 복사, AWS 계정간의 공유, Auto Scaling에도 활용할 수 있다.
Amazon Machine Image(AMI)
- 가상 서버에 있는 인스턴스 기동에 필요한 정보를 저장하고 있다.
- AMI 정보에는 OS, 아키텍처(32, 64bit), 가상화 방식(HVM, paravirtual), 인스턴스 기동 때에 Attach할 EBS 스냅샷 정보, 블록 디바이스 매핑 지점 등이 포함되어 있다.
- AMI는 단독으로 인스턴스를 생성하지 못하며, EBS 스냅샷과 함께 사용해야 인스턴스를 생성할 수 있다.
EBS 스냅샷
- EBS를 백업해서 S3에 저장하는 기능이다.
- 백업 방식은 이전의 EBS 스냅샷에서 변경된 현재 EBS의 변경 사항만 백업하는 증분 백업이다.
- 변경 사항이 많을수록 EBS 스냅샷을 생성하는데 오랜 시간이 걸린다.
AMI, EBS 스냅샷의 리전 간 복사
- AMI와 EBS 스냅샷은 다른 리전으로 복사해서 사용할 수 있다.
- 이런 기능을 활성화하면 여러 리전을 사용한 DR 환경을 쉽게 구현할 수 있다.
AMI, EBS 스냅샷의 AWS 계정간 공유
- AMI와 EBS 스냅샷은 공유할 AWS 계정 번호를 등록해서 같은 리전 내부에서 다른 AWS 계정과 공유할 수 있다.
- AMI를 공유하면 AMI 정보에 포함된 EBS 스냅샷도 공유된다.
- 특정 AWS 계정 뿐만 아니라 같은 리전 내부의 모든 AWS 사용자에게 AMI, EBS 스냅샷을 공개할 수 있다.
- 주의 사항
  - AWS 계정 공유는 같은 리전 내부에서만 이루어지므로, 다른 리전과 공유할 때는 이전에 언급한 리전 간의 복사 조작을 사용해야 한다.
AMI, EBS 스냅샷 비용
- AMI에는 비용이 들지 않는다.
- EBS 스냅샷에서 비용이 발생한다.
- 예시
  - 서울 리전에서 10GB로 10일동안 사용하면 다음과 같이 계산한다.
  - $0.005/월1GB * 10GB / 30일(1개월) * 10일 = $0.17

Amazon Simple Storage Service(S3)

S3
- 99%의 내구성을 실현한 스토리지다.
- REST, SOAP와 같은 단순 웹 서비스 인터페이스를 사용한다.
- 저장하는 데이터 양에 대한 비용도 저렴하고, 저장할 수 있는 데이터 양이 무한에 가깝다.
- FTP 서버처럼 단순 파일 저장 영역으로 사용할 수도 있으며, 다양한 AWS 서비스 사용 로그 저장, 정적 웹 사이트 호스팅 기능 등도 가지고 있다.
- 비용 체계와 사용 방법이 다르긴 하지만, 이전 절에 설명한 EBS 스냅샷의 저장 영역으로도 사용되고 있다.
- 빅 데이터 분석 데이터 소스로 활용하거나 On Premise 환경의 재난 복구 전용 데이터 백업, Auto Scaling을 활용한 EC2 인스턴스의 로그 저장 등으로 폭 넓게 활용할 수 있다.
S3 확장화 구성
- S3는 데이터를 저장할 때 자동적으로 여러 개의 데이터 센터에서 데이터를 동기화한다.
- 높은 견고성과 내결함성을 보장한다.
- 동기 처리는 S3에서 실행한 업데이트 작업은 시간이 어느 정도 지나면 반드시 반영한다는 최동 일관성(eventual consistency)을 채용하고 잇따.
- 데이터를 저장한 뒤에 여러 데이터 센터에서 동기화 하는 동안 데이터 읽기를 해버리면, 데이터 동기화가 완료되지 않은 데이터 센터의 데이터를 참조했을 때 이전 데이터를 읽을 가능성이 있으므로 주의해야 한다.
S3 버킷 객체의 개념
S3의 스토리지 옵션
S3 비용
S3 암호화
S3 접근 관리
S3 이벤트 알림
S3의 SLA
S3의 웹 호스팅 기능
EBS 스냅샷과 S3 객체의 차이
S3의 버전 관리
S3 수명 주기 설정

Amazon Glacier

Glacier 비용
Glacier의 SLA

프로그래머스 C++ 풀이 목록

Tue, 07 Jul 2020 00:00:00 +0000

algorithms/cpp/Programmers에 있는 프로그래머스 풀이 목록이다. C++ 풀이 154문제와 SQL 풀이 28문제를 레벨별로 나눴다. 항목을 누르면 풀이 파일로 간다.

CH03. 컨테이너 실전 구축 및 배포

Fri, 03 Jul 2020 00:00:00 +0000

1. 어플리케이션과 시스템 내 단일 컨테이너의 적정 비중

header
- 도커를 사용해 시스템을 구축한다는 것 = 자신이 만든 어플 컨테이너 + 공개된 어플/미들웨어 컨테이너
컨테이너 1개 = 프로새스 1개?

Network Device

Mon, 06 Jan 2020 09:34:37 +0900

200106 Monday ~ 200110 Friday

1. 계층별 장비와 케이블

계층 별 장비
- Physical Layer –> Repeater, Hub
- Data link Layer –> Switch, Bridge
- Network Layer –> Router, L3 Switch
Physical Layer :: Repeater

2. 프로그램의 구조를 쌓는다! 제어문

Fri, 29 Nov 2019 17:38:30 +0900

1. if문

형식

if [조건문]:
 # if의 조건식이 True일 때
 # 실행문
elif [조건문]:
 # elif의 조건식이 True일 때
 # 실행문
else:
 # 위의 조건식이 True인 것이 없을 때
 # 실행문

2장 : 깃으로 버전 관리하기

Fri, 29 Nov 2019 17:38:30 +0900

1. 깃 저장소

깃 초기화 하기
- 디렉토리를 하나 새로 만들고 내부를 살펴본 뒤 git init을 하면 .git이라는 디렉토리가 새로 생긴다.
- .git : 깃을 사용하면 버전이 저장될 ‘저장소’
```
$ mkdir hi-git
$ cd hi-git
$ ls -al
$ git init
$ ls -al
```

2. 버전 만들기

깃에서 버전이란
- 문서를 수정하고 저장할 때마다 생기는 것
- 원래 파일 이름은 그대로 유지하면서 파일에서 무엇을 변경했는지를 변경 시점마다 저장할 수 있다.
- 각 버전마다 작업했던 내용을 확인할 수 있고, 그 버전으로 rollback할 수 있다.
스테이지와 커밋 이해하기
- 작업트리 :: workspace
  - 파일 수정, 저장 등의 작업을하는 디렉토리
- 스테이지 :: index
  - 버전으로 만들 파일이 대기하는 곳
  - 명령어
```
$ git add [파일 또는 디렉토리]
```
- 저장소 :: local repository
  - 스테이지에 대기하고 있던 파일들을 버전으로 만들어 저장하는 곳
  - 명렁어
```
$ git commit -m "커밋 메시지 입력"
```
- 순서
  1.작업트리에서 작업을 한다.
  2.작업물을 스테이지에 올린다.
  3.스테이지에 있는 모든 것을 로컬 저장소에 저장한다.
- 스테이징과 커밋 한꺼번에 처리하기
  - 한 번이라도 커밋한 적이 있는 파일을 다시 커밋할 때 사용할 수 있다.
  - git commit -am "커밋 메시지"
- 현재 깃 상태 확인 :: git status
- 깃의 로그 확인 :: git log
  - 여러가지 옵션을 줄 수 있다.
  - 대표적인 옵션 :: –oneline, –branches, –graph
- 변경 사항 확인하기 :: git diff
  - 작업 디렉토리와 저장소의 차이를 볼 수 있다.
버전 만드는 단계마다 파일 상태 알아보기
- tracked 파일과 untracked 파일
  - untracked 파일 :: 한번도 깃에서 버전 관리를 하지 않았기 때문에 수정 내역을 추적하지 않음.
  - tracked 파일 :: untracked 파일이 아닌 파일
- unmodified, modified, staged 상태
  - tracked 파일의 상태 확인
  - unmodified : 커밋된 이후 수정되지 않은 상태
  - modified : 커밋된 이후 수정된 상태
  - staged : modified 상태에서 git add [파일 또는 폴더]를 실시하여 스테이지에 올려놓은 상태(커밋 직전의 상태)
  - 커밋을 실시하면 unmodified 상태로 돌아간다.
.gitignore 파일로 버전 관리에서 제외하기!
- 버전 관리 중인 디렉토리 안에 버전관리를 하지 않을 특정 파일 또는 디렉토리가 있다면 .gitignore 파일을 만들어 목록을 지정할 수 있다.
- 예시
```
$ cat .gitignore
mynote.txt # 파일을 ignore
temp/ # 폴더를 ignore
.swp # 확장자를 ignore
```
작업 되돌리기(Rollback)
- 작업트리에서 수정한 파일 되돌리기 :: git checkout -- [수정한 파일]
  - checkout으로 되돌린 내용은 다시 복구할 수 없습니다.
- 스테이징 되돌리기 :: git reset HEAD [파일이름]
  - 수정된 파일을 스테이징 했을 때, 스테이징을 취소한는 방법
- 최신 커밋 되돌리기 :: git reset HEAD^
  - 가장 마지막에 한 커밋을 취소하는 방법
  - git reset 명령의 옵션
    - git reset --soft HEAD^ : 최근 커밋을 하기 전 상태로 작업 트리를 되돌립니다.
    - git reset --mixed HEAD^ : 최근 커밋과 스테이징을 하기 전 상태로 작업 트리를 되돌린다. 기본값
    - git reset --hard HEAD^ : 최근 커밋과 스테이징, 파일 수정을 하기 전 상태로 작업 트리를 되돌린다. 되돌린 내용은 복구 불가능
    - HEAD^ 부분에 커밋해시를 넣어주면 특정 커밋 상태로 되돌아갈 수 있습니다.
  - 특정 커밋으로 되돌아간다면 그 이후의 버전을 삭제할 수 있다.
- 버전 삭제하지 않고 되돌리기 :: git revert [커밋 해쉬를 넣는다]
  - 나중에 사용할 것을 대비해서 커밋을 되돌리더라도 취소한 커밋을 남겨두어야 할 때가 있다.
  - 이때는 git reset이 아닌 git revert를 사용한다.

[2018] 다트 게임

Thu, 21 Nov 2019 00:00:00 +0000

문제 출처

규칙
1. 다트 게임은 총 3번의 기회로 구성된다.
2. 각 기회마다 얻을 수 있는 점수는 0 ~ 10점까지이다.
3. 점수와 함께 S(점수의 1승), D(점수의 2승), T(점수의 3승)가 주어진다.
4. 옵션으로 *(해당 점수와 이전에 얻은 점수를 각각 2배로 한다), #(해당 점수를 마이너스한다)이 존재한다.
5. *는 첫번째 기회에도 등장할 수 있으며, 이 때 해당점수만 2배로 한다.
6. *, #은 둘 중 하나만 존재하거나 존재하지 않을 수 있다.
7. S, D, T는 점수마다 하나씩 존재한다.
입력 형식 : 1S2D*3T(점수 | 보너스 | [ 옵션 ] )

[DS] Single Linked List

Fri, 15 Nov 2019 00:00:00 +0000

Single Linked List (단순 연결 리스트)

1. 개념

하나의 노드에 필요한 정보를 담고 다음에 해당하는 노드를 가리키고 있는 자료구조로 포인터를 이용해 자료들을 선형으로 연결한 자료구조이다.
[ 배열 ] 과 비교했을 때 추가 및 삭제가 쉽다는 장점이 있지만 접근할 때 O(n)만큼 걸린다는 단점이 있습니다.

2. 구현

List를 구성할 노드를 생성하고 기본적인 기능을 추가합니다.
- private 멤버 변수
  - data : 노드의 값
  - pnext : 현재 노드의 다음을 알려주는 포인터
- public 멤버 함수
  - Node(), Node(T) : 생성자
  - getData() : 노드의 data를 리턴한다.
  - setData() : 노드의 data를 설정한다.
  - getNext() : 현재 노드의 다음 노드를 리턴한다.
  - setNext() : 현재 노드의 다음 노드를 설정한다.

template <class T>
class Node
{
private:
	T data;
	Node<T>* pnext;
public:
	Node();
	Node(T);
	T getData() { return this->data; }
	void setData(T n) { this->data = n; }
	singlenode<T>* getNext() { return this->pnext; }
	void setNext(singlenode<T>* pnode) { this->pnext = pnode; }
};
template <class T>
Node<T>::Node()
{
	this->data = 0;
	this->pnext = NULL;
}
template <class T>
Node<T>::Node(T n)
{
	this->data = n;
	this->pnext = NULL;
}

Node가 들어갈 List의 틀(class)을(를) 생성하고 필요한 기능과 멤버 변수를 추가해줍니다.
- private 멤버 변수
  - phead : List의 가장 앞 부분을 알려준다.
  - ptail : List의 끝을 알려준다.
  - ssize : List에 들어있는 노드의 갯수를 알려준다.
- public 멤버 함수
  - SingleLinkedList() : 생성자
  - isEmpty() : List가 비어있다면 True, 아니면 False
  - size() : List에 들어있는 노드의 갯수를 리턴한다.
  - getHead() : List의 가장 앞 부분을 알려주는 phead를 리턴한다
  - getData(), AddFront(), AddBack(), InsertNode(), DeleteNode()

template <class T>
class SingleLinkedList
{
private:
	Node<T>* phead;
	Node<T>* ptail;
	int ssize;
public:
	SingleLinkedList();
	bool isEmpty() { return this->phead == NULL ? true : false; }
	int size() { return this->ssize; }
	Node<T>* getHead() { return this->phead; }
	T getData(int);
	void AddFront(T);
	void AddBack(T);
	void InsertNode(Node<T>*, T);
	void DeleteNode(int);
};

멤버 함수 상세 내용

테이블

Wed, 19 Apr 2023 00:00:00 +0000

개념

테이블의 컬럼과 행

컬럼(Column) : 테이블에 저장될 데이터의 특성을 지정
행(Row) : 컬럼에 정의된 형식으로 저장된 데이터를 의미

데이터 타입

Number Data Type

SW Expert Academy 풀이 목록

Sun, 02 Aug 2020 00:00:00 +0000

algorithms/cpp/SWExpertAcademy에 있는 SW Expert Academy C++ 풀이 86문제의 목록이다. 난이도(D2~D4)별로 나눴고, 번호를 누르면 풀이 파일로 간다. 풀이 과정을 적은 글은 SW Expert Academy Solution 시리즈에 있다.

4장 쉘 프로그래밍 문법

Wed, 22 Jul 2020 00:00:00 +0000

Bourne Shell(sh)의 문법을 중심으로 설명한다.

CH04. 스웜을 이용한 실전 어플리케이션 개발

Wed, 01 Jul 2020 00:00:00 +0000

1. 웹 어플리케이션 구성

어플리케이션의 요구 조건
- TODO를 등록, 수정, 삭제할 수 있다.
- 등록된 TODO의 목록을 출력할 수 있다.
- 브라우저에서 사용할 수 있는 웹 어플리케이션이다.
아키텍처
- 오케스트레이션 시스템은 도커 스웜 사용

Linux Basic

Mon, 13 Jan 2020 10:31:27 +0900

200116 Thurday ~ 200116 Thursday

1. Linux(리눅스)

리눅스란?
- 컴퓨터 운영체제의 한 종류
- 윈도우와는 다르게 오픈 소스 운영체제
- 소스코드가 공개되어 있기 때문에 다양한 리눅스 기반의 운영체제가 존재
  - 구글의 안드로이드도 리눅스를 기반으로 만든 운영체제
운영체제란?

3. 프로그램의 입력과 출력

Fri, 29 Nov 2019 17:38:30 +0900

1. 함수

입력값을 가지고 어떤 일을 수행한 다음에 그 결과물을 내어놓는 것.
코드의 재사용
반복적으로 사용되는 가치 있는 부분
파이썬 함수의 구조
```
def 함수명(입력 인수):
 수행할 문장1
 수행할 문장2
 ...
```
```
def 함수명(입력 인수):
 수행할 문장
 ...
 return 결과값
```
- 입력 인수가 없을 수 있다.
- 입력 인수가 여러 개일 수 있다.
- 결과값이 없는 함수일 수 있다.
- 입력 인수와 결과값이 둘 다 없는 함수일 수 있다.

입력값이 몇 개가 될지 모를 때(**)

def sum_many(*args):
 sum = 0
 for i in args:
 sum += i
 return sum

res = sum_many(1, 2, 3, 4)
print(res)

입력값이 몇 개가 될지 모를 때(**)

def call(**kwargs):
 for key, value in kwargs.items():
 print("{0} is {1}".format(key, value))

call(a=1, b=2, c=3)

입력 인수에 초깃값 미리 설정하기

def say_myself(name, old, man=True):
 print("나의 이름 {0}".format(name))
 print("나의 나이 {0}".format(old))
 if man:
 print("남자")
 else:
 print("여자")

say_myself('Sam', 27)
say_myself('Jane', 27, False)

함수 안에서 선언된 변수의 효력 범위

함수 안에서 선언된 변수는 함수 안에서 수명을 다한다.

a = 1
def life(a):
 a += 1 # 함수가 끝날 때 까지 a 는 2이다.

print(a) # a 는 1이다.
life(a)
print(a) # a 는 1이다.

a = 1
def life():
 global a # 함수 외부에 있는 a에 직접 접근한다.
 a += 1

life()
print(a)

a = 1
def life(a):
 a += 1
 return a # 결과값을 주고 a에 대입한다.

a = life(a) # 호출과 대입
print(a)

2. 사용자 입력과 출력

사용자 입력
- input()을 통해서 사용자에게 입력을 받을 수 있다.

출력

print()를 통해서 프롬프트에 출력할 수 있다.

for i in ragne(10):
 print(i, end=' ')

문자열 띄어쓰기는 콤마로 한다.

print("life""is""too ""short")
print("life""is""too", "short")
print("life"+"is"+"too", "short")

3. 파일 입출력

파일 생성

3장 : 깃과 브랜치

Fri, 29 Nov 2019 17:38:30 +0900

1. 브랜치(branch)

분기점
- master에서 commit한다.
- 현 상태에서 Feature-1 브랜치를 만들어 새로운 내용을 추가하여 commit한다.
- master에서 새로운 내용을 넣어 commit한다.
- 현 상태에서 Feature-2 브랜치를 만들어 새로운 내용을 추가하여 commit 한다.
- Feature-1과 master를 merge(병합)한다.
- Feature-2와 master를 merge(병합)한다.

2. 브랜치 만들기

실습 환경 설정하기
```
$ mkdir branchtest
$ cd branchtest
$ git init
$ vim work.txt
$ git add work.txt
$ git commit -m "work 1"
```
- 새로운 저장소를 만든다.
- 새로운 파일을 만들고 commit까지 실시한다.
새 브랜치 만들기
- 브랜치 확인 :: git branch
- 브랜치 생성 :: git branch [브랜치 이름]
```
$ git branch
$ git branch apple
$ git branch ms
$ git branch google
```
브랜치 이동하기 :: git checkout [브랜치 이름]
- master에서 work.txt를 수정하고 커밋한다.
- git log --oneline으로 로그를 보면 master와 다른 브랜치의 상태가 다른 것을 확인 할 수 있다.
- apple 브랜치로 이동하여 git log --oneline으로 로그를 보면 HEAD가 apple를 가리키고 있는 것을 볼 수 있다.
- work.txt를 cat으로 확인해보면 master에서 수정한 내용이 반영되지 않았음을 확인할 수 있다.

3. 브랜치 정보 확인하기

apple에서 work.txt를 수정하고 커밋한다.
git log --oneline --branches --graph를 한다면 분기되었음을 그래프로 확인할 수 있다.
git log master..apple : master 브랜치를 기준으로 apple과 비교하여 차이점을 알 수 있다.
git log apple..master : apple 브랜치를 기준으로 master와 비교하여 차이점을 알 수 있다.

4. 브랜치 병합하기

서로 다른 파일 병합
- 새로운 저장소를 만든다.
- work.txt 파일을 만들어 ‘1’을 입력하고 저장
- add 해주고 commit을 실행하는데 메시지를 “work 1"으로 한다.
- b1 브랜치를 생성해준다.
- master 브랜치에서 master.txt 파일을 만들어 ‘master 2’를 입력하고 저장
- “master work 2"라는 메시지와 함께 커밋
- b1 브랜치로 이동하여 b1.txt 파일을 만들어 ‘b1 2’를 입력하고 저장
- “b1 work 2"라는 메시지와 함께 커밋
- git log --oneline --branches --graph로 현재 상태를 확인한다.
- master 브랜치로 이동하여 git merge b1을 입력하여 병합한다. :: master 브랜치를 b1과 병합한 결과를 master 브랜치에 적용한다.
```
$ mkdir man1
$ cd man1
$ git init
$ vim work.txt
$ git add work.txt
$ git commit -m "work 1"
$ git branch b1
$ vim master.txt
$ git add master.txt
$ git commit -m "master work 2"
$ git checkout b1
$ vim b1.txt
$ git add b1.txt
$ git commit -m "b1 work 2"
$ git log --oneline --branches --graph
$ git checkout master
$ git merge b1
$ ls -al
```
같은 파일 다른 위치 수정후 병합
- 새로운 저장소를 만든다.
- work.txt 파일을 만들어 아래와 같이 입력하고 저장
```
#title
content


#title
content
```
- add 해주고 commit을 실행하는데 메시지를 “work 1"으로 한다.
- b1 브랜치를 생성해준다.
- master 브랜치에서 work.txt 파일을 아래와 같이 수정하여 “master work 2” 메시지로 커밋한다.
```
#title
master content 2


#title
content
```
- b1 브랜치로 이동하여 work.txt 파일을 아래와 같이 수정하여 “b1 work 2” 메시지로 커밋한다.
```
#title
content


#title
b1 content 2
```
- master 브랜치로 이동하여 merge를 실시한 뒤 work.txt를 cat으로 확인하면 자연스럽게 합쳐진 모습을 볼 수 있다.
```
$ git init man2
$ cd man2
$ vim work.txt
$ git add work.txt
$ git commit -m "work 1"
$ git branch b1
$ vim work.txt
$ git commit -am "master work 2"
$ git checkout b1
$ vim work.txt
$ git commit -am "b1 work 2"
$ git checkout master
$ git merge b1
$ cat work.txt
```
같은 파일 같은 위치 수정후 병합
- 깃에서는 줄 단위로 변경여부를 확인한다.
- 같은 줄을 수정했을 때 브랜치를 병합하면 브랜치 충돌이 발생
- 새로운 저장소를 만든다.
- work.txt 파일을 만들어 아래와 같이 입력하고 저장
```
#title
content

#title
content
```
- add 해주고 commit을 실행하는데 메시지를 “work 1"으로 한다.
- b1 브랜치를 생성해준다.
- master 브랜치에서 work.txt 파일을 아래와 같이 수정하여 “master work 2” 메시지로 커밋한다.
```
#title
content
master content 2
#title
content
```
- b1 브랜치로 이동하여 work.txt 파일을 아래와 같이 수정하여 “b1 work 2” 메시지로 커밋한다.
```
#title
content
b1 content 2
#title
content
```
- master 브랜치로 이동하여 merge를 실시하면 CONFLICT 메시지가 출려된다.
- 편집기로 work.txt를 열어서 필요없는 내용 <<<<HEAD, >>>>b1, =====을 삭제한 뒤 저장하고 편집기를 종료한다.
- 수정한 work.txt를 스테이지에 올리고 커밋하면 충돌을 해결하고 커밋한 것이다.
- git log --oneline --branches --graph로 지금까지 만든 브랜치와 커밋의 관계를 한눈에 확인할 수 있다.
```
$ git init man2
$ cd man2
$ vim work.txt
$ git add work.txt
$ git commit -m "work 1"
$ git branch b1
$ vim work.txt
$ git commit -am "master work 2"
$ git checkout b1
$ vim work.txt
$ git commit -am "b1 work 2"
$ git checkout master
$ git merge b1
$ vim work.txt
$ git commit -am "merge b1 branch"
$ git log --oneline --branches --graph
```
브랜치를 병합할 때 편집기
- 편집기 열리게 하기 : git merge b1 --edit
- 편집기 열리지 않게 하기 : git merge b1 --no-edit
병합 및 충돌 해결 프로그램

프로그램	설명
P4Merge	무료이고 직관적이며 사용이 편리하고 병합 기능이 뛰어남. 단축키가 지원되지 않는 단점이 있다.
Meld	무료이며 오픈소스. 파일을 비교하는 것뿐만 아니라 직접 편집할 수 있다.
Kdiff3	무료이고 사용이 편리하고 병합 기능이 뛰어나지만 한글이 깨져보일 수 있다.
Araxis Merge	유료지만 용량이 큰 파일에서도 잘 동작함

병합이 끝난 브랜치 삭제
- git branch로 남은 브랜치 확인
- 저장소의 기본 브랜치는 master 브랜치이므로 master 브랜치로 이동하여 브랜치를 삭제하는 것이 안전하다.
- b1 브랜치의 삭제
  - git branch -d b1
  - git branch --delete b1
  - git branch -D b1

5. 브랜치 관리하기

커밋 해시를 통해서 브랜치들을 관리하고 커밋 해시(버전)으로 rollback 할 수 있다.
수정 중인 파일 감추기 및 되돌리기 :: git stash
- 아직 커밋하지 않고 작업 중인 파일들을 잠시 감춰둘 수 있다.
- stash 명령을 사용하기 위해선 파일이 tracked 상태여야 한다.(한 번은 커밋한 상태여야 한다)
- 새로운 저장소를 만들고 f1.txt, f2.txt를 생성하고 커밋한다.
- f1.txt와 f2.txt를 수정하고 저장만 한 뒤 git status로 상태를 확인한다.
- 각각의 파일이 modified 상태인 것을 확인 할 수있다.
- git stash를 실시하고 다시 git status를 해보면 modified 메시지가 사라진 것을 확인 할 수 있다.
- 같은 방법으로 여러 파일을 수정한 후 따로 보관할 수 있다.
- stash가 보관되는 공간은 stack으로 이루어져 LIFO이 적용된다.
  - 가장 최근에 보관한 stash는 stash@{0}에 담기게 된다.
- 감추어둔 파일을 꺼내와 계속 수정하거나 커밋할 수 있다.
- 이때 가장 최근 항목을 되돌리기 위해서 git stash pop을 사용한다.
```
$ git init st
$ cd st
$ vim f1.txt
$ vim f2.txt
$ git add .
$ git commit -m "add f1, f2"
$ vim f1.txt
$ vim f2.txt
$ git stash
$ git stash pop
```
stash 관련 명령어
- git stash : stash 스택에 modified 상태의 작업물을 담는다.
- git stash pop : 가장 최근의 항목을 되돌리고 stash 스택에서 제거한다.
- git stash list : stash 스택의 목록을 확인한다.
- git stash apply : 가장 최근의 항목을 되돌리고 stash 스택에 남겨둔다.
- git stash drop : 가장 최근의 항목을 삭제한다.

[2018] 뉴스 클러스터링

Sun, 24 Nov 2019 00:00:00 +0000

문제 출처

문제 설명
1. 자카드 유사도
  - 집합 A = { 1, 2, 3 }, 집합 B = { 2, 3, 4 }
  - A ∩ B = { 2, 3 }
  - A ∪ B = { 1, 2, 3, 4 }
  - J(A, B) = 2 / 4
  - 자카드 유사도는 0.5이다.
2. 중복을 허용하는 다중집합에서의 자카드 유사도
  - 집합 A = { 1, 1, 2, 2, 3 }, 집합 B = { 1, 2, 2, 4, 5 }
  - A ∩ B = { 1, 2, 2 }
  - A ∪ B = { 1, 1, 2, 2, 3, 4, 5 }
  - J(A, B) = 3 / 7
  - 자카드 유사도는 약 0.42이다.
3. 자카드 유사도를 문자열 사이에 적용
  - 두 글자씩 끊어서 다중집합을 만든다.
  - FRANCE -> { FR, RA, AN, NC, CE }, FRENCH -> { FR, RE, EN, NC, CH }
  - 교집합 = { FR, NC }
  - 합집합 = { FR, NC, RA, AN, CE, RE, EN, CH }
  - J(FRANCE, FRENCH) = 2 / 8
  - 자카드 유사도는 0.25이다.
4. 비교에 있어서 대문자와 소문자의 차이는 무시한다.
5. 다중집합을 만듦에 있어서 두 문자가 영문자일 경우에만 집합에 포함한다.
  - “ab+“문자가 있으면 “ab"는 포함하고 “b+“는 포함하지 않는다.
6. 유사도는 0에서 1사이의 실수이므로 65536을 곱한 후에 소수점 아래를 버린다.
문제 풀이

[2018] 프렌즈 4 블록

Thu, 21 Nov 2019 00:00:00 +0000

문제 출처

같은 모양의 카카오프렌즈 블록이 2×2 형태로 4개가 붙어있을 경우 사라지면서 점수를 얻는 게임이다.

[DS] Queue

Fri, 15 Nov 2019 00:00:00 +0000

Queue(큐)

1. 개념

Queue는 FIFO(First In First Out)의 원리로 동작하는 자료구조이다.
동일한 자료의 집합을 다룬다는 면에서 Stack과 비슷하지만 가장 먼저 들어간 자료가 가장 늦게 나온다는 점이 다르다.
넣은 순서대로 자료를 꺼내가므로 순서대로 처리해야 하는 자료를 임시작으로 저장하는 용도로 흔히 사용한다.
저장되는 자료의 타입이 동일하므로 배열 또는 연결리스트로 Queue를 구현할 수 있다.

프로그래머스 Python 풀이 노트

Thu, 02 Oct 2025 00:00:00 +0000

algorithms/notebooks/programmers.ipynb에 정리한 프로그래머스 Python 풀이를 글로 옮겼다. 문제 제목을 누르면 프로그래머스 문제 페이지로 간다. 뒤쪽에는 python/programmers의 초기 스크립트 풀이 6개를 붙였다.

인덱스

Wed, 19 Apr 2023 00:00:00 +0000

개념

인덱스란?

SQL의 조회 성능을 향상시키기 위해서 테이블과는 별도로 생성되는 오브젝트

5장 시스템 관리 쉘 스크립트

Fri, 24 Jul 2020 00:00:00 +0000

5.1 디스크 사용량 분석/보고

5.1.1 쉘 스크립트 코드

#!/bin/bash

# 점검 용량 MB 단위 설정
SETSIZE=10
EXMB=`expr $SETSIZE\*\(1024\*1024\)`

# UID가 500 이상인 계정을 구분한다.
for name in $(cut -d: -f1,3 /etc/passwd | awk -F: '$2 > 499 {print $1}')
do
 echo "사용자 $name의 $SETSIZE MB 초과 파일 목록 / 용량"
 find /user/tmp/home -user $name -type f -ls | awk "\$7 > $EXMB" | awk '{print "경로:" $11, "/ 용량:" $7}'
 echo ""
done
exit

5.1.2 실행 결과

$ ./5-1.sh
사용자 nobody의 10 MB 초과 파일 목록 / 용량

사용자 ubuntu의 10 MB 초과 파일 목록 / 용량

사용자 user01의 10 MB 초과 파일 목록 / 용량

사용자 user02의 10 MB 초과 파일 목록 / 용량

5.1.3 코드 분석
- 점검할 용량을 MB 단위로 설정하는 부분, 이후 점검 파일과 비교하기 위해 expr 명령어를 이용해 바이트 단위로 변환한다.
```
SETSIZE=10
EXMB=`expr $SETSIZE\*$1024\*1024$`
```
- /etc/passwd 에서 UID가 500 이상인 계정을 대상으로 cut 명령어를 이용하여 첫 번째 필드와 세 번째 필드를 구분한다.
```
for name in $(cut -d: -f1,3 /etc/passwd | awk -F: '$2 > 499 {print $1}')
```
- name에 할당된 계정 소유자가 소유한 파일의 용량을 비교하여 설정된 용량보다 큰 파일의 경로와 세부 용량을 표시한다.
```
echo "사용자 $name의 $SETSIZE MB 초과 파일 목록 / 용량"
find /user/tmp/home -user $name -type f -ls | awk "\$7 > $EXMB" | awk '{print "경로:" $11, "/ 용량:" $7}'
```

5.2 사용자 계정 일시 정지

5.2.1 쉘 스크립트 코드

#!/bin/sh

stime=90 		
ami=`whoami`

if [ "$ami" != "root" ]; then
 echo "★본 프로그램은 체계관리자(ROOT)외 사용자는 실행이 제한됩니다. ★"
 exit
fi

# $1 not exist
if [ -z $1 ]
 then
 echo "usage : 5-2.sh username"
 exit
fi

echo "◆ $1의 사용자 계정을 일시정지합니다. a ~ d 단계로 진행합니다."
echo ""
echo " a $1 계정의 패스워드를 변경해주세요"
echo ""
passwd $1

tty=`who | grep $1 | tail -1 | awk '{print $2}'`

if [ -z $tty ]
 then echo ""
 else
 cat << EOF > /dev/$tty
*************************************************************
★경 고 ★
지금 사용하고 있는 계정은 시스템관리자에게 의해 일시정지되니
90초 이후에는 강제 Log Out 됩니다.
지금하는 작업을 마무리하시고 Log Out 바랍니다.

계정사용 연장 및 기타문의사항은 시스템관리부서에 문의하세요
 ☎053-972-1234~8
*************************************************************
EOF
 sleep $stime
fi

killall -s HUP -u $1
sleep 1
killall -s KILL -u $1
echo " b $1의 사용중인 모든 프로세스는 종료되었습니다."
echo " c 현 시각부로 계정 $1 은 Log Out 되었습니다. "
echo " - $(date) - "

chmod 000 /home/$1
echo " d $1 계정은 일시 정지 처리되었습니다."
exit

5.2.2 실행 결과

$ ./5-2.sh ubuntu
◆ ubuntu의 사용자 계정을 일시정지합니다. a ~ d 단계로 진행합니다.

a ubuntu 계정의 패스워드를 변경해주세요

Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully

b ubuntu의 사용중인 모든 프로세스는 종료되었습니다.
c 현 시각부로 계정 ubuntu 은 Log Out 되었습니다.
 - Fri Jul 24 05:13:53 UTC 2020 -
d ubuntu 계정은 일시 정지 처리되었습니다.

5.2.3 코드 분석

#!/bin/sh

# 슬립 타임을 설정한다.
stime=90
# 현재 사용자를 알아온다.
ami=`whoami`

# 계정 일시 정지는 root 사용자만 가능하도록 한다.
if [ "$ami" != "root" ]; then
 echo "★본 프로그램은 체계관리자(ROOT)외 사용자는 실행이 제한됩니다. ★"
 exit
fi

# 인자가 없으면 usage를 나타낸다.
if [ -z $1 ]
 then
 echo "usage : 5-2.sh username"
 exit
fi

echo "◆ $1의 사용자 계정을 일시정지합니다. a ~ d 단계로 진행합니다."
echo ""
echo " a $1 계정의 패스워드를 변경해주세요"
echo ""
# 비밀번호 변경을 위한 작업
# user가 존재하지 않는 경우는 배제한다.
passwd $1

# 프롬프트는 1개 열려 있다는 가정에서 열려있는 프롬프트에 접근한다.
tty=`who | grep $1 | tail -1 | awk '{print $2}'`

if [ -z $tty ]
 # 열려있는 프롬프트가 없다면
 then echo ""
 # 열려있는 프롬프트가 있다면 알림을 보내준다.
 else
 cat << EOF > /dev/$tty
*************************************************************
★경 고 ★
지금 사용하고 있는 계정은 시스템관리자에게 의해 일시정지되니
90초 이후에는 강제 Log Out 됩니다.
지금하는 작업을 마무리하시고 Log Out 바랍니다.

계정사용 연장 및 기타문의사항은 시스템관리부서에 문의하세요
 ☎053-972-1234~8
*************************************************************
EOF
 sleep $stime
fi

# 프롬프트 프로세스를 종료시킨다.
killall -s HUP -u $1
sleep 1
killall -s KILL -u $1
echo " b $1의 사용중인 모든 프로세스는 종료되었습니다."
echo " c 현 시각부로 계정 $1 은 Log Out 되었습니다. "
echo " - $(date) - "

# home path에 접근하지 못하도록 계정을 비활성화 한다.
chmod 000 /home/$1
echo " d $1 계정은 일시 정지 처리되었습니다."
exit

5.3 guest 및 공용 계정 초기화

5.3.1 쉘 스크립트 코드

#!/bin/sh

sampledir="/tmp/sample/"
ami=`whoami`

if [ "$ami" != "root" ]; then
 echo "★본 프로그램은 체계관리자(ROOT)외 사용자는 실행이 제한됩니다. ★"
 exit
fi

# /etc/passwd에서 user로 시작하는 계정을 추출한다.
for name in $(cat /etc/passwd | awk -F: '/^user/{print $1}')
do 
 cd /home/$name
 rm -r ./* 
 cp -rp /$sampledir /home/$name/

 echo " ■사용자 $name 의 홈디렉토리 초기화 완료"
 echo ""
done 
exit

5.3.2 실행 결과

$ ./5-3.sh
■사용자 B311148 의 홈디렉토리 초기화 완료

■사용자 B311146 의 홈디렉토리 초기화 완료

5.3.3 코드 분석

#!/bin/sh

# 기본값으로 구성되어 있는 초기 상태의 user
# 없다면 새로 생성해야 한다.
sampledir="/tmp/sample/"
# 현재 사용자를 알기 위해
ami=`whoami`

# root 유저만 초기화할 수 있도록 설정한다.
if [ "$ami" != "root" ]; then
 echo "★본 프로그램은 체계관리자(ROOT)외 사용자는 실행이 제한됩니다. ★"
 exit
fi

# /etc/passwd에서 B로 시작하는 계정을 추출한다.
for name in $(cat /etc/passwd | awk -F: '/^B/{print $1}')
do 
 cd /home/$name
 rm -r ./* 
 cp -rp /$sampledir /home/$name/

 echo " ■사용자 $name 의 홈디렉토리 초기화 완료"
 echo ""
done 
exit

5.4 서버의 네트워크 상태 감시

5.4.1 쉘 스크립트 코드

5-4.sh

#!/bin/sh

serIP="/test/ch_5/serverIP.lst"

# /test/ch_5/serverIP.lst에서 서버의 IP를 추출한다.
for ip in $(cat $serIP | awk -F: '{print $2}')
do 
 sername=`grep $ip $serIP | awk -F: '{print $1}'`

 if ! ping -c 2 $ip >> /dev/null 
 then 
 echo ""
 echo " ★ $sername 서버 또는 네트워크 접속 제한 : 점검요망 ★"

 grep $sername $serIP >> /test/ch_5/Server_chk_err_`date +%C%y%m%d`.log
 fi
done 
exit

serverIP.lst

WAS:192.168.3.128
DB_1:192.168.3.129
DB_2:192.168.3.120
ftp:192.168.3.131
mail:192.168.3.132

5.4.2 실행 결과

$ ./5-4.sh

★ WAS 서버 또는 네트워크 접속 제한 : 점검요망 ★

★ DB_1 서버 또는 네트워크 접속 제한 : 점검요망 ★

★ DB_2 서버 또는 네트워크 접속 제한 : 점검요망 ★

★ ftp 서버 또는 네트워크 접속 제한 : 점검요망 ★

★ mail 서버 또는 네트워크 접속 제한 : 점검요망 ★

ping 점건 결과 이상이 있는 시스템을 화면에 표시하고, 점건이 필요한 서버를 Server_chk_err_날짜.log 파일에 저장한다.
서버이름:서버IP 형식으로 log 파일에 저장된다.

5.4.3 코드 분석

#!/bin/sh

# 형식에 맞게 파일이 작성되어있어야 한다.
serIP="/test/ch_5/serverIP.lst"

# /test/ch_5/serverIP.lst에서 서버의 IP를 추출한다.
for ip in $(cat $serIP | awk -F: '{print $2}')
do 
 sername=`grep $ip $serIP | awk -F: '{print $1}'`

 if ! ping -c 2 $ip >> /dev/null 
 then 
 echo ""
 echo " ★ $sername 서버 또는 네트워크 접속 제한 : 점검요망 ★"

 grep $sername $serIP >> /test/ch_5/Server_chk_err_`date +%C%y%m%d`.log
 fi
done 
exit

5.5 서비스 프로세스 상태 점검

5.5.1 쉘 스크립트 코드 a
5.5.2 실행 결과 a
5.5.3 코드 분석 a
5.5.4 쉘 스크립트 코드 b
5.5.5 실행 결과 b
5.5.6 코드 분석 b

5.6 특정 디렉터리의 파일 내용 일괄 수정하기

5.6.1 쉘 스크립트 코드
5.6.2 실행 결과
5.6.3 코드 분석

5.7 지정된 날짜의 웹 접속 통계

5.7.1 쉘 스크립트 코드
5.7.2 실행 결과
5.7.3 코드 분석

5.8 점검 결과를 메일로 보고

5.8.1 쉘 스크립트 코드
5.8.2 실행 결과
5.8.3 코드 분석

5.9 ftp를 이용한 파일 전송 자동화

5.9.1 쉘 스크립트 코드
5.9.2 실행 결과
5.9.3 코드 분석

5.10 cron 스케줄 등록

5.10.1 쉘 스크립트 코드
5.10.2 실행 결과
5.10.3 코드 분석

5.11 데몬 및 서비스 프로세스의 시작과 정지

5.11.1 쉘 스크립트 코드
5.11.2 실행 결과
5.11.3 코드 분석

5.12 로그 파일 로테이션

5.12.1 쉘 스크립트 코드 a
5.12.2 실행 결과 a
5.12.3 코드 분석 a
5.12.4 쉘 스크립트 코드 b
5.12.5 실행 결과 b
5.12.6 코드 분석 b

CH05. 쿠버네티스 입문

Wed, 01 Jul 2020 00:00:00 +0000

1. 쿠버네티스란 무엇인가?

INTRO
- 컨테이너 운영을 자동화하기 위한 컨테이너 오케스트레이션 도구( 구글의 주도로 개발되었다. )
- 컨테이너를 이용한 어플리케이션 배포할 수 있다.
- 다양한 운영 관리 업무를 자동화할 수 있다.
- 컨테이너 배치, 스케일링, 로드벨런싱, 헬스 체크 등 기능을 갖추고 있다.
도커의 부상과 쿠버네티스의 탄생

Linux

Thu, 16 Jan 2020 13:35:04 +0900

200116 Thursday ~ 2001?? ????sday

4. 파이썬 날개 달기, 클래스

Fri, 29 Nov 2019 17:38:30 +0900

1. 파이썬 프로그래밍의 핵심, 클래스

한 클래스로 만들어진 두 인스턴스는 독립적인 개체이다.

4장 : 깃허브로 백업하기

Fri, 29 Nov 2019 17:38:30 +0900

1. 원격 저장소와 깃허브

원격 저장소
- 지역 저장소가 아닌 컴퓨터나 서버에 만든 저장소를 말한다.
- 지역 저장소와 연결되어 있으면서 ‘백업’과 ‘협업’이라는 중요한 역할을 한다.
깃허브로 할 수 있는 일
- 원격 저장소에서 깃을 사용할 수 있다.
- 지역 저장소를 백업할 수 있다.
- 헙업 프로젝트에 사용할 수 있다.
- 자신의 개발 이력을 남길 수 있다.
- 다른 사람의 소스를 살펴볼 수 있고, 오픈 소스에 참여할 수 있다.

2. 깃허브 시작하기

깃허브에 접속한 뒤 계정을 생성한다.
무료 계정과 유료 계정의 차이 : 협업할 수 있는 계정의 수가 제한되어 있다.
깃허브에 원격 저장소 만들기
- repository를 새로 만들어 원격 저장소를 추가할 수 있다.
- Add a License : 오픈 소스 프로젝트를 위한 저장소를 만들 경우 해당 오픈 소스의 라이센스를 선택한다.

3. 지역 저장소를 원격 저장소와 연결하기

지역 저장소를 만든다.
- git init [지역 저장소 이름]
지역 저장소와 원격 저장소를 연결한다.
- git remote add [원격 저장소 이름] [원격 저장소 URL]
- 원격 저장소 이름 : 사용자 지정
- github에서 지정되어 있는 URL :: clone or download를 눌렀을 때 나오는 URL
지역 저장소와 원격 저장소의 연결 확인
- git remote -v

4. 원격 저장소에 올리기 및 내려받기

원격 저장소에 파일 올리기 :: git push
- git push origin master
  - push : 원격 저장소에 올리겠다.
  - origin : 원격 저장소의 이름
  - master : 원격 저장소에 올릴 브랜치
원격 저장소에서 파일 받기 :: git pull
- git pull origin master
  - pull : 원격 저장소에서 받아오겠다.
  - origin : 원격 저장소의 이름
  - master : 원격 저장소에 받아올 브랜치이름, 지역 저장소의 브랜치 이름

5. 깃 허브에 SSH 원격 접속하기

생략하도록 하겠다…
필요시 업데이트 하겠다…

5장 : 깃허브로 협업하기

Fri, 29 Nov 2019 17:38:30 +0900

1. 여러 컴퓨터에서 원격 저장소 함께 사용하기

원격 저장소 복제하기 :: git clone
- git clone [복사할 원격 저장소의 URL]
- 위와 같이 사용하여 원격 저장소에서 복제할 수 있다.(복제한다 == 클론 == 클로닝)
- git clone [복제할 저장소의 URL] [복제할 디렉토리]
- 복제할 디렉토리가 없으면 새로 생성해준다.
- 복제할 디렉토리를 넣지 않으면 원격 저장소의 이름과 동일하게 복제된다.
실습을 위한 두 환경 준비
- 두 환경을 만들어 각각 회사와 집이라고 생각하자.
- git_home
  - git clone [URL] git_home
- git_office
  - git clone [URL] git_office

개인 컴퓨터에서 작업하고 올리기

$ cd git_home
$ vim f1.txt
$ git commit -m "add c"
$ git push origin master

회사 컴퓨터에서 내려받아 작업하기

$ cd ~/git_office
$ git pull origin master
$ vim f1.txt
$ git commit -am "add d"
$ git push origin master

작업을 함에 있어서 항상 git pull을 통해서 원격 저장소에 새로 올라온 커밋을 가져와야한다.

2. 원격 브랜치 정보 가져오기

git pull
- 명령은 원격 저장소의 최신 커밋을 지역 저장소에 합쳐준다. 하지만 최신 커밋을 합치기 전에 원격 저장소에 어떤 변화가 있는지 먼저 살펴보아야 한다.

원격 브랜치 정보 가져오기 :: git fetch

fetch(패치) : 불러오다, 가져오다
git fetch : 어떤 변화가 있는지 원격 저장소의 정보를 가져온다.

$ cd ~/git_office
 # 원격 저장소에서 변경을 실시한다.
$ git fetch
$ git log --oneline 
 # 변화된 부분이 없다...
$ git status
 # git pull 명령을 사용하면 지역 저장소를 업데이트 할 수 있다고 한다.
$ git checkout FETCH_HEAD
 # 이제 변화된 부분을 확인할 수 있다.
$ git checkout master
$ git merge FETCH_HEAD
$ git log --oneline
 # 커밋 로그를 확인해보면 적용되어 있다.

3. 협업의 기본 알아보기

공동 작업자 추가하기(팀장)
- 누구나 프로젝트의 소스를 내려받을 수 있지만 커밋을 푸시할 순 없다.
- 공동 작업자가 커밋을 푸시할 수 있도록 권하는 주는 것이다.

작업 환경 구성하기(팀장, 팀원)

$ git init project
$ cd project
 # --global 옵션을 제거하여 현재 저장소에만 적용될 config입니다.
$ git config user.name "사용자 이름"
$ git config user.email 사용자@이메.일

원격 저장소에 첫 커밋 푸시하기(팀장)

$ vim overview.txt
$ git add overview.txt
$ git commit -m "overview"

새로운 깃허브 저장소를 만든다.

$ git remote add origin [저장소 URL]
$ git push origin master

공동 작업자 컴퓨터에서 원격 저장소 복제하기

$ git clone [저장소 URL]
 # 사용자 이름과 이메일을 설정한다.

첫 번재 커밋(팀장이 실시한)이 아니라면 풀 먼저하기
- 팀원이 작업트리에서 작업을 수행함에 있어서 팀장이 그 중에 푸시를 실시할 수 있다.
- 팀원이 작업을 완료하고 푸시하려고 할 때 팀장의 새로운 커밋이 푸시되었으므로 rejected라는 오류 메시지가 나온다.
- 이를 방지하기위해서 푸하기전에 항상 풀을 먼저 실시해야 한다.
- 같은 파일을 수정했을 경우 풀 과정에서 merge 에러가 발생할 수 있다.
- 이럴경우 수동으로 이를 해결해주어야 한다… 귀찮다…

4. 협업에서 브랜치 사용하기

협업을 하다 보면 팀원들이 각자 기능을 맡아서 작업하는 경우가 많다.
이럴 때는 각자의 작업이 master 브랜치에 있는 문서들과 섞이지 않도록 새 브랜치를 만들어서 버전을 관리한다.
각 팀원이 만든 새 브랜치 역시 원격 저장소에 그대로 푸시할 수 있다.

새로 만든 브랜치 푸시하기

$ git pull origin master
 # checkout 명령에 -b 옵션을 붙여 브랜치를 새로 만들고 이동까지 한번에
 # f 브랜치가 있다면 브랜치로 이동
$ git checkout -b f
$ vim f1.txt
$ git add f1.txt
$ git add f1.txt
$ git commit -m "feature1"
$ git push origin f

웹 브라우저로 원격 저장소로 접속하면 브랜치가 생성되어 있다.

풀 리퀘스트로 푸시한 브랜치 병합하기
1. 브랜치 설명 옆에 있는 New pull request를 누른다.
2. 풀 리퀘스트 메시지를 작성한 후 Create pull request를 누르면 협업 중인 저장소에 풀 리퀘스트가 전송된다.
3. 협업 중인 원격 저장소에 등록된 풀 리퀘스트는 공동 작업자 중 누구나 살펴보고 병합할 수 있다. 저장소 파일 위의 Pull request를 누르면 등록된 풀 리퀘스트 목록이 나타난다. 등록된 풀 리퀘스트를 누른다.
4. 풀 리퀘스트 메시지를 살펴본 다음 내용에 문제가 없으면 Merge pull request를 눌러 병합을 한다. 필요하다면 이 공간을 통해 풀 리퀘스트를 남간 사람과 메시지를 주고받을 수 있다.
5. 커밋 메시지를 직접 입력하거나 기본 메시지를 사용할 수도 있다. Confirm merge를 누르면 브랜치 병합이 끝난다.
6. 브랜치가 병합되면 해당 브랜치에 있던 파일이 master 화면에 나타날 것이다. 브랜치 상태를 알고 싶다면 파일 목록 위에 있는 2 branches를 눌러 보시오.
7. 브랜치가 병합된 상태라면 merged라고 표시되어 있다. 그리고 공동 작업자 중 누가 브랜치를 병합했는지도 알 수 있다.
8. 깃허브에서 협업할 때는 보통 작업자마다 브랜치를 만들어서 진행하고, 작업 중간 중간 풀 리퀘스트를 보내서 master 브랜치에 병합한다. 그래서 깃허브로 협업할 때는 다른 작업자의 변경 내용을 바로 반영하기 위해서 항상 풀부터 한 다음 자신의 작업을 진행하는 것이 좋다.

[2018] 비밀지도

Sat, 23 Nov 2019 00:00:00 +0000

문제 출처

문제 설명
1. 지도는 한 변의 길이가 n 인 정사각형 배열 형태로, 각 칸은 공백 또는 “#“으로 이루어져 있다.
2. 전체 지도는 두 장의 지도를 겹쳐서 얻을 수 있다. 지도A, 지도B
3. 두 지도는 각각 정수 배열로 암호화 되어 있다.
4. 암호화된 배열은 지도의 각 가로줄에서 벽 부분을 1, 공백부분을 0으로 부호화했을 때 얻어지는 이진수에 해당한는 값의 배열이다.

[DS] Stack

Fri, 15 Nov 2019 00:00:00 +0000

Stack(스택)

1. 개념

가장 늦게 들어간 자료가 가장 먼저 나가는 구조이다.
후입선출(LIFO, Last In First Out)이라고도 부른다.
Stack에 데이터를 넣는 행동을 push, 데이터를 빼는 행동을 pop이라 한다.
Stack의 가장 위 데이터를 가르키는 포인터를 top이라고 한다.

CH06. 쿠버네티스 클러스터 구축

Wed, 01 Jul 2020 00:00:00 +0000

1. Google Kubernetes Engine 환경 설정

4장에서 구축한 TODO 어플리케이션을 쿠버네티스로 전환하고 GKE를 사용해서 배포할 것이다.

인프라 환경 변화의 시작, 클라우드

Thu, 26 Mar 2020 00:00:00 +0000

1.1 클라우드 컴퓨팅의 정의와 종류

클라우드 컴퓨팅의 정의
- 클라우드 컴퓨팅은 인터넷이 가능한 디바이스로 제 3의 공간인 클라우드에서 데이터를 읽고 쓰고, 정보를 분석해 처리하며, 이를 저장하고 관리하는 컴퓨팅 시스템입니다.
클라우드 서비스의 종류

5. 파이썬 정규 표현식과 XML

Fri, 29 Nov 2019 17:38:30 +0900

1. 정규 표현식 살펴보기

정규식의 필요성
- 장황한 parsing을 간편하고 직관적인 코드로 대체할 수 있다.

data = """
park 800905-1049118
kim 700905-1059119
"""

result = []
for line in data.split('\n'):
 word_result = []
 for word in line.split(' '):
 if len(word) == 14 and word[:6].isdigit() and word[7:].isdigit():
 word = word[:6] + "-" + "*******"
 word_result.append(word)
 result.append(' '.join(word_result))
print('\n'.join(result))

import re

data = """
park 800905-1049118
kim 700905-1059119
"""

pat = re.compile("(\d{6})[-]\d{7}")
print(pat.sub("\g<1>-*******", data))

2. 정규 표현식 시작하기

정규 표현식에서 사용하는 메타문자 : . ^ $ * + ? { } [ ] \ | ( )

[2018] 셔틀버스

Fri, 22 Nov 2019 00:00:00 +0000

문제 출처

문제 설명
1. 셔틀은 09:00 부터 총 n 회 t 분 간격으로 역에 도착하며, 하나의 셔틀에는 최대 m 명의 승객이 탈 수 있다.
2. 셔틀은 도착했을 때 도착한 순간 대기열에 선 크루까지 포함해서 대기 순서대로 태우고 바로 출발한다. 예를 들어 09:00 에 도착한 셔틀은 자리가 있다면 09:00 에 줄을 선 크루도 탈 수 있다.
3. 콘(셔틀을 탈 승객)은 게으르기 때문에 같은 시각에 도착한 크루 중 대길에서 제일 뒤에 선다.
4. 콘이 셔틀을 타고 사무실로 갈 수 있는 제일 늦은 시각을 출력한다.
풀이

[C++ STL] Queue

Sat, 16 Nov 2019 20:08:14 +0900

Queue

내부적으로는 deque, list로 구성되어 있다.
queue구조로 동작하도록 멤버 함수를 제공해준다.

CH07. 쿠버네티스 실전편

Wed, 01 Jul 2020 00:00:00 +0000

1. 쿠버네티스의 그 외 리소스

INTRO
- 쿠버네티스는 데몬으로 동작하는 서버 어플리케이션 외에도 배치 서버 등 다양한 형태의 어플리케이션을 구축할 수 있다.
잡(Job)

오픈스택이란?

Thu, 26 Mar 2020 00:00:00 +0000

2.1 오픈스택의 역사

역사에 대한 내용은…
Pass 하겠다…
요청이 있다면 다루겠다…
사실 구글링하면 다나옴…
올리기 귀찮으니까…
올리지 않겠음…
추가된 새 기능은 블로그에 계속 업데이트 된다.
필자의 블로그

2.2 오픈스택과 아키텍처

오픈스택은 컴퓨트, 오브젝트 스토리지, 이미지, 인증 서비스 등이 유기적으로 연결되어 하나의 커다란 클라우드 컴퓨팅 시스템을 구축한다.

[2018] 추석 트래픽

Sat, 23 Nov 2019 00:00:00 +0000

문제 출처

처리량의 변화가 어디서 일어나는지 알아내는 것에 어려움이 있었다. 큰 문제를 작은 문제로 나누어 풀어나간다는 것에 초점을 두고 하나의 로그데이터를 살펴보았을 때 어디서 처리량의 변화가 일어나는지 확인하였다. 이 과정에서 시간이 정말 오래걸렸다.

[C++ STL] Vector

Sat, 16 Nov 2019 20:08:14 +0900

개념

vector는 자동으로 메모리가 할당되는 배열이라고 생각하면 됩니다.
template를 사용하기 때문에 데이터 타입은 마음데로 넣을 수 있습니다.
Stack과 비슷한 구조를 가지고 있으며, 맨 뒤에서 삽입과 삭제가 가능합니다.
중간의 값을 삭제하거나 삽입이 가능하지만, 배열기반이므로 삽입과 삭제가 빈번하게 일어난다면 효율이 떨어집니다.

기본 생성법

<vector> 헤더파일을 추가해야한다.

CH08. 컨테이너 운영

Wed, 01 Jul 2020 00:00:00 +0000

1. 로깅 운영

INTRO
- 컨테이너 환경의 효율적인 로그 관리 등 관리 운영적 부분에 중접을 두고 운영 환경에서 알아둬야 할 주의 사항을 설명한다.
컨테이너에서 생성되는 로그
- 비컨테이너 환경
  - 서버 업타임이 길기 때문에 로그가 누적되어 상당한 디스크 용량을 차지하는 일이 자주 발생한다.
- 도커
  - 로그 라이브러리를 사용해도 로그가 파일이 아니라 표준 출력으로 출력하고 이를 다시 Fluentd 같은 로그 컬렉터로 수집하는 경우가 많다.
  - 어플리케이션 쪽에서 로그 로테이션을 할 필요가 없으며 로그 전송을 돕는 로깅 드라이버 기능도 갖추고 있으므로 로그 수집이 편리하다.
- 표준 출력과 로그
  - gihyodocker/echo:latest 사용
  - 포어그라운드로 실행한 다음 http://localhost:8080으로 요청을 보내면 표준 출력으로 출력된다.
```
$ docker container run -it --rm -p 8080:8080 gihyodocker/echo:latest
2020/06/26 02:19:53 start server
2020/06/26 02:20:18 received request
```
  - 호스트에 컨테이너 데이터가 저장되는 디렉터리 : /var/lib/docker/containers/컨테이너ID
  - 컨테이너 데이터가 저장되는 디렉터리에 컨테이너ID-json.log 파일이 로그 파일이다.
```
# 컨테이너ID : 9b0eb43784afcc61efb36de58c4115931a0fa51fb87629ee6cff8624e0dd999a
$ tail /var/lib/docker/containers/[컨테이너ID]/[컨테이너ID]-json.log
```
    또는
```
# 로그파일 있는 곳을 볼륨으로 컨테이너 생성
$ docker container run -it --rm -v /var/lib/docker/containers:/json-log alpine ash
/ # cd json-log/[컨테이너ID]
json-log/[컨테이너ID]/ # ls
json-log/[컨테이너ID]/ # tail [컨테이너ID]-json.log
```
  - 컨테이너 표준 출력으로 출력된 내용이 JSON 포맷으로 출력된 것을 확인할 수 있다.
  - 어플리케이션에서 로그를 파일에 출력하도록 구현하지 않았더라도 도커에서 컨테이너의 표준 출력을 로그로 출력해 주는 것이다.
  - 로그 출력 자체를 완전히 도커에 맡길 수 있다.

로깅 드라이버

로그가 JSON 포맷으로 출력되는 이유는 도커에 json-file이라는 기본 로깅 드라이버가 있기 때문이다.
로깅 드라이버 : 도커 컨테이너가 출력하는 로그를 어떻게 다룰지를 제어하는 역할을 한다.

종류	설명
Syslog	syslog로 로그를 관리
Journald	systemd로 로그를 관리
Awslogs	AWS CloudWatch Logs로 로그를 전송
Gcplogs	Google Cloud Logging으로 로그를 전송
Fluentd	fluentd로 로그를 관리

컨테이너 로그 다루기
- 장애로 인해 예기치 않게 컨테이너가 정지되고 디스크에서 완전히 삭제되었다면 컨테이너 안에 로그를 파일로 남기면 컨테이너를 삭제할 때 로그도 함께 잃어버린다는 큰 문제가 발생한다.
- 방법
  - 호스트에서 컨테이너에 공유한 볼륨에 파일로 로그를 남기는 방법
  - 로그를 표준 출력으로 남기고 이 내용을 호스트에서 파일에 수집하는 방법
  - 도커에서는 후자를 정석으로 여긴다.
- 컨테이너 로그의 로테이션
  - 도커 컨테이너 로깅 동작 제어 옵션 : –log-opt
    - –log-opt max-size=1m : 로테이션이 발생하는 로그 파일 최대 크기
    - –log-opt max-file=5 : 최대 파일 개수. 이 값을 초과할 경우 오래된 파일부터 삭제된다.
```
$ docker container run -it --rm -p 8080:8080 --log-opt max-size=1m --log-opt max-file=5 gihyodocker/echo:latest
```
    - max-size로 설정한 파일 크기에 도달하면 파일이 로테이션된다.
      ----.log # 최신 ----.log.1 # 이전 로그
    - 이 설정은 컨테이너마다 일일이 할 필요는 없고, 도커 데몬에서 log-opts 기본값으로 설정할 수 있다.
      - /etc/docker/daemon.json
        { "log-driver" : "json-file", "log-opts" : { "max-size" : "10m", "max-file" : "5" } }
Fluentd와 Elasticsearch를 이용한 로그 수집 및 검색 기능 구축
- 파일 기반의 로그 관리 방식은 번거롭다.

[2019] 블록 게임

Sun, 24 Nov 2019 00:00:00 +0000

문제 출처

문제 설명
1. 아래와 같이 12가지 모양의 블록이 배치되어 있다.

CH09. 가벼운 도커 이미지 만들기

Thu, 02 Jul 2020 00:00:00 +0000

도커 이미지의 최적하 보다는 어플리케이션의 동작을 우선시했다.
일정 규모 이상의 어플리케이션을 본격적으로 구축하려면 도커 이미지 크기에도 신경 써야 한다.

1. 가벼운 도커 이미지가 왜 필요할까

이미지 크기 증가에 따라 나타는 문제
- 이미지 크기가 미치는 영향
  - 이미지 빌드 시간(기반 이미지 다운로드 시간 포함)
  - 이미지를 도커 레지스트리에 등록하는 시간
  - 컨테이너를 실행할 호스트 혹은 노드에서 이미지를 다운로드하는 시간
- 나비효과
  - 클러스터를 구성하는 노드의 디스크 용량 낭비
  - CI 소요 시간 증가
  - 개발 중 시행착오 소요 시간 증가로 인한 생산성 저하
  - 오토 스케일리으로 컨테이너가 투입되는 소요 시간 증가(노드에 이미지가 없는 경우 새로 받아와야 하므로)
- 새 노드에 얼마나 빨리 도커 이미지를 배치할 수 있는가가 중요하다.

2. 기반 이미지를 가볍게

scratch
- INTRO
  - 빈 도커 이미지로, 도커가 이름을 예약한 특수 이미지다.
  - Dockerfile의 FROM 인스트럭션에서 참조만 가능하다.
  - 컨테이너 외부로부터 파일을 주입받은 후에야 실체를 갖게 된다.
  - 현재 존재하는 모든 도커 이미지의 기반 이미지를 따라가 보면 결국 이 scratch 이미지에 이르게 된다.
  - scratch 이미지는 모든 이미지의 조상 격이다.
- scratch 이미지로 만든 이미지 빌드 들여다보기
  - ubuntu:trusty 이미지의 Dockerfile
```
FROM scratch

ADD ubuntu-trusty-core-cloudimg-amd64-root.tar.gz /

RUN set -xe \
 \
 && echo '#!/bin/sh' > /usr/sbin/policy-rc.d \
 && echo 'exit 101' >> /usr/sbin/policy-rc.d \
 && chmod +x /usr/sbin/policy-rc.d \
 \
 && dpkg-divert --local --rename --add /sbin/initctl \
 && cp -a /usr/sbin/policy-rc.d /sbin/initctl \
 && sed -i 's/^exit.*/exit 0/' /sbin/initctl \
 \
 && echo 'force-unsafe-io' > /etc/dpkg/dpkg.cfg.d/docker-apt-speedup \
 \
 && echo 'DPkg::Post-Invoke { "rm -f /var/cache/apt/archives/*.deb /var/cache/apt/archives/partial/*.deb /var/cache/apt/*.bin || true"; };' > /etc/apt/apt.conf.d/docker-clean \
 && echo 'APT::Update::Post-Invoke { "rm -f /var/cache/apt/archives/*.deb /var/cache/apt/archives/partial*.deb /var/cache/apt/*.bin || true"; };' >> /etc/apt/apt.conf.d/docker-clean \
 && echo 'Dir::Cache::pkgcache ""; Dir::Cache::srcpkgcache "";' >> /etc/apt/apt.conf.d/docker-clean \
 \
 && echo 'Acquire::Languages "none";' > /etc/apt/apt.conf.d/docker-no-languages \
 \
 && echo 'Acquire::GzipIndexes "true"; Acquire::CompressionTypes::Order:: "gz";' > /etc/apt/apt.conf.d/docker-gzip-indexes \
 \
 && echo 'Apt::AutoRemove::SuggestsImportant "false";' > /etc/apt/apt.conf.d/docker-autoremove-suggests

RUN rm -rf /var/lib/apt/lists/*

RUN sed -i 's/^#\s*$deb.*universe$$/\1/g' /etc/apt/sources.list

CMD ["/bin/bash"]
```
    - ubuntu-trusty-core-cloudimg-amd64-root.tar.gz : 우분투 운영체제를 구성하는 최소한의 파일을 디렉토리 구조 그대로 압축한 것
    - ADD 인스트럭션은 COPY와 다르게 압축해제 기능이 있다.
    - CMD 인스트럭션에 /bin/bash 명령을 지정하여 컨테이너가 /bin/bash를 포어그라운드로 실행하므로 우분투 서버 자체가 상주 형태로 실행되는 것처럼 보인다.
- 어플리케이션을 실행하는데 운영 체제를 구성하는 파일을 모두 사용하는 것은 아니기 때문에 대부분의 파일은 쓸모없이 이미지의 용량만 차지한다.
- 간단한 이미지 만들기
  - hello.go 작성
```
package main
import "fmt"

func main() {
 fmt.Println("hello, scratch!")
}
```
  - 바이너리를 복사할 수 있도록 컨테이너 밖에서 컴파일한다.
```
$ GOOS=linux GOARCH=amd64 go build hello.go
```
  - Dockerfile 작성
```
FROM scratch

COPY hello /

CMD ["/hello"]
```
  - 이미지 빌드
```
$ docker image build ch09/hello:latest .
```
  - 컨테이너 실행
```
$ docker container run -t ch09/hello:latest
```
  - 이미지 크기 확인
```
$ docker image ls | grep hello
```
  - 프로그래밍 언어로 된 어플리케이션은 언어 런타임이나 라이브러리 등을 이미지에 포함해야 하므로 Go 언어에 비해서 이미지가 커지는 경향이 있다.
- 네이티브 라이브러리 링크
  - C언어나 Go 언어에서 빌드한 실행 바이너리를 컨테이너에 복사하기만 하면 된다.
  - 어플리케이션이 동적 링크를 사용하는 경우 주의해야 한다.
  - 빌드시 네이티브 의존 라이브러리를 정적 링크하도록 하면 이미지를 만드는 수고를 크게 덜 수 있다.
- 루트 인증서
  - TLS/SSL이 적용된 웹 사이트에 접근
  - hello.go 수정
```
package main
import (
 "fmt"
 "io/ioutil"
 "net/http"
)

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

 resp, err := http.Get("https://gihyo.jp/")
 if err != nil {
 panic(err)
 }
 defer resp.Body.Close()
 body, err := ioutil.ReadAll(resp.Body)
 if err != nil {
 panic(err)
 }

 fmt.Println(string(body))
}
```
  - 이 어플리케이션을 빌드하고 컨테이너로 실행하면 인증서 오류가 발생한다.
  - TLS/SSL이 적용된 HTTPS 웹 사이트에 접근하려면 루트 인증서가 필요하다.
  - 일반적인 운영체제라면 루트 인증서가 포함되지만 scratch 이미지에는 루트 인증서 자체가 없기 때문에 오류가 발생한다.
  - Dockerfile 수정
```
FROM scratch

COPY hello /
COPY cacert.pem /etc/ssl/certs/

CMD ["/hello"]
```
  - 운영 체제가 포함된 이미지라면 패키지 관리자를 통해 필요한 라이브러리나 도구를 추가할 수 있지만 scratch 이미지에는 패키지 관리자 같은 것이 존재하지 않는다.
- scratch 이미지의 실용성
  - scratch 이미지에서 동작하려면 빌드부터 시작해야 하는 것은 물론, 다양한 의존 모듈이 필요하다.
  - 디버그를 하려고 해도 셸이 없기 때문에 컨테이너 안의 상황을 파악하기가 어렵다.
  - 이 점은 이미지의 크기와 트레이드 오프 관계를 가지므로 이러한 부분을 포기하더라도 작은 이미지가 필요한 상황이라면 scratch도 선택지에 포함시킬 수 있다.
busybox
- INTRO
  - busybox는 임베디드 시스템에서 많이 사용하는 리눅스 배포판이다.
  - busybox는 수백 종 이상의 기본 유틸리티를 갖추고 있다.
  - 일반적인 운영 체제와 달리, 단일 바이너리 파일(/bin/busybox)에 모든 유틸리티가 포함된 형태다.
  - 모든 명령어 파일이 /bin/busybox로 하드 링킹되어 있다.
- 표준 C 라이브러별 이미지
  - glibc
    - GNU C 라이브러리를 의미한다.
    - 다양한 스펙 및 독자적인 확장 기능을 제공하기 때문에 유연하지만 그만큼 라이브러리 크기가 크다.
    - 잘 사용하지 않는 기능 때문에 디스크 용량을 낭비한다는 문제가 있다.
  - uclibc
    - 임베디드 환경에 특화된 가벼운 라이브러리로 추린 것이다.
  - musl
    - musl은 정적 링크에 최적화되어 있어 어플리케이션을 이동에 유리한 단일 바이너리로 빌드하기에 좋다.
    - POSIX 표준을 더 충실히 구현한다.
  - 아키텍처나 운영 체제가 다른 환경에서 glibc로 빌드한 바이너리는 uClibc나 musl을 사용한 컨테이너에서 실행이 되지 않는다.
  - 빌드 환경과 실행 환경의 차이를 배제하기 위해 -glibc, -uclibc, -musl과 같은 라이브러리별 이미지를 제공한다.
- busybox의 실용성
  - 최소한의 운영 체제 기능을 제공하면서도 운영 체제로 인한 이미지 크기 증가는 거의 제로에 가깝게 줄여준다.
  - busybox를 포함한 이미지는 scratch로 만든 이미지보다 1MB 정도 크기가 크지만, 셸을 포함하고 있어 컨테이너 안에서 디버깅 작업이 가능하다.
  - 에이전트 타입 어플리케이션이나 명령행 도구를 사용하는데 사용할 수 있다.(scratch와 마찬가지로)
  - 패키지 관리자가 없다.
  - 이미지 크기에 구애받지 않거나 이미지 빌드가 까다로운 경우에는 우분투나 CentOS 등의 이미지를 사용하는 것이 편리하다.
alpine
- INTRO
  - busybox를 기반으로 한 리눅스 배포판으로 ‘보안, 간결함, 리소스 효율을 중시하는 파워 유저’를 대상으로 설계했으며, 표준 C 라이브러리 구현체 중 musl을 사용한다.
  - 리눅스 배포판의 표준이라고 할 수 있다.
  - 패키지 관리자인 apk를 사용할 수 있다.
  - Dockerfile의 내용이 너무 장황하거나 이미지 빌드에 필요한 사전 준비가 지나치게 늘어나면 이미지 전체 내용을 파악하기 어려워진다. 이런 문제를 해결하려면 쓸 만한 패키지 관리자가 반드시 필요하다.
- alpine 컨테이너 실행하기
```
$ docker container run -it alpine:3.7 sh
```
- 패키지 관리자 apk 사용법
  - apk의 패키지 리포지토리가 중앙 집권적이라는 특징이 있다.
  - apk update : 로컬에 캐싱된 apk 패키지 인덱스를 업데이트하는 명령.
  - apk search : 현재 사용할 수 있는 패키지를 검색하는 명령.
  - apk add : 패키지를 설치하는 명령.
    - --no-cache 옵션
      - /var/cache/apk 디렉터리에 저장된 apk 인덱스 대신 새로 받아온 인덱스 정보를 이용해 패키지를 설치한다.
      - /var/cache/apk 디렉터리에 캐시를 저장하지 않으므로 이 디렉터리의 내용을 따로 삭제할 필요도 없다.
    - --virtual 옵션
      - 여러 패키지를 합쳐 하나의 별명을 붙이는 기능을 제공한다.
      - 빌드 시에만 필요한 이미지를 그대로 남겨두면 이미지 크기가 불필요하게 증가할 수 있으므로 이 라이브러리를 제거하는 것이 좋다.
      - 불필요한 패키지를 한번에 제거할 수 있다.(apk del [별명])
  - apk del : 설치된 패키지를 제거하는 명령
- 알파인 리눅스 기반 도커 이미지 만들기
  - 2장의 echo를 사용한다.
  - main.go
```
import (
 "fmt"
 "log"
 "net/http"
)

func main() {
 log.Println("start server")

 bind = ":8080"

 http.HandleFunc("/", func(w http.ResponseWriter, r * http.Request){
 log.Println("received request")
 fmt.Fprintf(w, "Hello Docker!!!")
 })

 http.ListenAndServe(bind, nil)
}
```
  - Dockerfile
```
FROM alpine:3.7

# (0) workspace 등록 및 환경 변수 등록
WORKDIR /
ENV GOPATH /go

# (1) 빌드 시에만 필요한 라이브리 및 도구 설치
RUN apk add --no-cache --virtual=build-devs go git gcc g++

# (2) 실행 시에도 필요한 라이브리 및 도구 설치
RUN apk add --no-cache ca-certificates

# (3) echo를 빌드해 실행 파일을 만듬
COPY . /go/src/github.com/lameld/echo
RUN cd /go/src/github.com/lameld/echo && go build -o bin/echo main.go
RUN cd /go/src/github.com/lameld/echo && cp bin/echo /usr/local/bin/

# (4) 빌드 시에만 필요한 라이브러리 및 도구 제거
RUN apk del --no-cache build-devs

CMD ["echo"]
```
  - 이미지 빌드
```
$ docker image build -t ch09/echo:latest .
```

3. 가벼운 도커 이미지 만들기

배포 대상 어플리케이션 크기 줄이기
- 어플리케이션 크기 최적화
  - 불필요한 파일 삭제
  - 불필요한 프로그램 최소화
  - 의존 라이브러리 최소화
  - 웹 어플리케이션의 애셋(주로 이미지) 용량 줄이기
- .dockerignore 파일
  - 불필요한 파일 및 디렉터리가 컨텡너에 들어가지 않게 하는 것이 중요하다.
  - .git 디렉토리로 대표되는 불필요함 숨김 파일이 컨테이너에 들어가기 쉽다.
  - Dockerfile과 같은 디렉토리에에 위치차 .dockerignore 파일에 컨테이너 포함하지 않을 파일이나 디렉토리를 정의하는 기능이다.
  - .dockerignore
```
.git
.idea
*.swp
*.log
.DS_STORE
```

도커 이미지의 레이어 구조 고려하기

INTRO

이미지의 크기를 최적화하려면 이 내부 구조까지 깊이 이해할 필요가 있다.
echo 이미지를 빌드해 보면 다음과 같은 내용이 출력된다.

각 단계별로 Dockerfile에 기술된 명령이 실행되는 것을 알 수 있다.

$ docker image build -t ch09/echo:latest .
Sending build context to Docker daemon 3.072kB
Step 1/10 : FROM alpine:3.7
---> 6d1ef012b567
Step 2/10 : WORKDIR /
---> Using cache
---> 96f74ddcf3b7
Step 3/10 : ENV GOPATH /go
---> Using cache
---> acaeee72e27d
Step 4/10 : RUN apk add --no-cache --virtual=build-devs go git gcc g++
---> Using cache
---> fa4f43acbc98
Step 5/10 : RUN apk add --no-cache ca-certificates
---> Using cache
---> 1ad9964de84c
Step 6/10 : COPY . /go/src/github.com/lameld/echo
---> Using cache
---> f84186eefbc7
Step 7/10 : RUN cd /go/src/github.com/lameld/echo && go build -o bin/echo main.go
---> Using cache
---> 77ffccfd40f7
Step 8/10 : RUN cd /go/src/github.com/lameld/echo && cp bin/echo /usr/local/bin/
---> Using cache
---> 56242e05b9ce
Step 9/10 : RUN apk del --no-cache build-devs
---> Using cache
---> 9d06ac4d82e2
Step 10/10 : CMD ["echo"]
---> Using cache
---> 7bce58ed9dea
Successfully built 7bce58ed9dea
Successfully tagged ch09/echo:latest

해당 이미지가 어떤 레이어로 구성되었는지 자세한 정보 보기 : docker image history

$ docker image history ch09/echo:latest
IMAGE CREATED CREATED BY SIZE COMMENT
7bce58ed9dea 2 minutes ago /bin/sh -c #(nop) CMD ["echo"] 0B 
9d06ac4d82e2 2 minutes ago /bin/sh -c apk del --no-cache build-devs 34kB 
56242e05b9ce 2 minutes ago /bin/sh -c cd /go/src/github.com/lameld/echo… 7.52MB 
77ffccfd40f7 2 minutes ago /bin/sh -c cd /go/src/github.com/lameld/echo… 7.52MB 
f84186eefbc7 2 minutes ago /bin/sh -c #(nop) COPY dir:afb826e60552ed0da… 713B 
1ad9964de84c 2 minutes ago /bin/sh -c apk add --no-cache ca-certificates 515kB 
fa4f43acbc98 2 minutes ago /bin/sh -c apk add --no-cache --virtual=buil… 359MB 
acaeee72e27d 3 minutes ago /bin/sh -c #(nop) ENV GOPATH=/go 0B 
96f74ddcf3b7 3 minutes ago /bin/sh -c #(nop) WORKDIR / 0B 
6d1ef012b567 16 months ago /bin/sh -c #(nop) CMD ["/bin/sh"] 0B 
<missing> 16 months ago /bin/sh -c #(nop) ADD file:aa17928040e31624c… 4.21MB

각 레이어에 해당하는 이미지는 도커 파일 시스템 안에 tar.gz 파일에 저장된다.
레이어 자체도 이미지이며, 중간 과정에 특정한 태그를 붙일 수 있다.
```
$ docker image tag f84186eefbc7 ch09/echo:copy
```

레이어의 수를 최대한 줄이기

이미지를 구성하는 레이어 자체도 이미지 파일 형태로 디스크에 존재한다.
때문에 빌드 중에 필요했던 파일도 최종 결과물이 될 이미지에서 불필요한 파일이라면 결국 최종 이미지에 불필요한 파일에 들어간다.

entrykit 이미지

Dockerfile

FROM alpine:3.7

RUN apk add --no-cache wget
RUN wget https://github.com/progrium/entrykit/releases/download/v0.4.0/entrykit_0.4.0_Linux_x86_64.tgz
RUN tar -xvzf entrykit_0.4.0_Linux_x86_64.tgz
RUN rm entrykit_0.4.0_Linux_x86_64.tgz
RUN mv entrykit /bin/entrykit
RUN chmod +x /bin/entrykit
RUN entrykit --symlink

이미지 빌드

$ docker image build -t ch09/entrykit:standard .
Sending build context to Docker daemon 2.048kB
Step 1/8 : FROM alpine:3.7
---> 6d1ef012b567
Step 2/8 : RUN apk add --no-cache wget
---> Using cache
---> 9ddb2b2b256e
Step 3/8 : RUN wget https://github.com/progrium/entrykit/releases/download/v0.4.0/entrykit_0.4.0_Linux_x86_64.tgz
---> Using cache
---> bbb9cf07b1a2
Step 4/8 : RUN tar -xvzf entrykit_0.4.0_Linux_x86_64.tgz
---> Using cache
---> 72ed24750e29
Step 5/8 : RUN rm entrykit_0.4.0_Linux_x86_64.tgz
---> Using cache
---> 063c338b89b0
Step 6/8 : RUN mv entrykit /bin/entrykit
---> Using cache
---> 13ae51cb1f1b
Step 7/8 : RUN chmod +x /bin/entrykit
---> Using cache
---> dbfc1a91f15f
Step 8/8 : RUN entrykit --symlink
---> Using cache
---> 5e6c02d2e7c0
Successfully built 5e6c02d2e7c0
Successfully tagged ch09/entrykit:standard

이미지 레이어

$ docker image history ch09/entrykit:standard
IMAGE CREATED CREATED BY SIZE COMMENT
5e6c02d2e7c0 5 minutes ago /bin/sh -c entrykit --symlink 32B 
dbfc1a91f15f 5 minutes ago /bin/sh -c chmod +x /bin/entrykit 9.19MB 
13ae51cb1f1b 5 minutes ago /bin/sh -c mv entrykit /bin/entrykit 9.19MB 
063c338b89b0 5 minutes ago /bin/sh -c rm entrykit_0.4.0_Linux_x86_64.tgz 0B 
72ed24750e29 5 minutes ago /bin/sh -c tar -xvzf entrykit_0.4.0_Linux_x8… 9.19MB 
bbb9cf07b1a2 5 minutes ago /bin/sh -c wget https://github.com/progrium/… 2.71MB 
9ddb2b2b256e 6 minutes ago /bin/sh -c apk add --no-cache wget 480kB 
6d1ef012b567 16 months ago /bin/sh -c #(nop) CMD ["/bin/sh"] 0B 
<missing> 16 months ago /bin/sh -c #(nop) ADD file:aa17928040e31624c… 4.21MB

각 레이어에서 파일을 조작할 때마다 최종 이미지의 크기가 증가함을 알 수 있다.
이런 현상을 피하려면 Dockerfile을 빌드 해 생성되는 이미지의 레이어 수를 줄이는 것이 가장 효과적이다.

Dockerfile.light

FROM alpine:3.7

RUN apk add --no-cache wget && \
wget https://github.com/progrium/entrykit/releases/download/v0.4.0/entrykit_0.4.0_Linux_x86_64.tgz && \
tar -xvzf entrykit_0.4.0_Linux_x86_64.tgz && \
rm entrykit_0.4.0_Linux_x86_64.tgz && \
mv entrykit /bin/entrykit && \
chmod +x /bin/entrykit && \
entrykit --symlink

이미지 빌드

$ docker image built -f Dockerfile.light -t ch09/entrykit:light .
Sending build context to Docker daemon 3.072kB
Step 1/2 : FROM alpine:3.7
---> 6d1ef012b567
Step 2/2 : RUN apk add --no-cache wget && wget https://github.com/progrium/entrykit/releases/download/v0.4.0/entrykit_0.4.0_Linux_x86_64.tgz && tar -xvzf entrykit_0.4.0_Linux_x86_64.tgz && rm entrykit_0.4.0_Linux_x86_64.tgz && mv entrykit /bin/entrykit && chmod +x /bin/entrykit && entrykit --symlink
---> Using cache
---> b504a789d31f
Successfully built b504a789d31f
Successfully tagged ch09/entrykit:light

이미지 레이어

$ docker image history ch09/entrykit:light
IMAGE CREATED CREATED BY SIZE COMMENT
b504a789d31f About a minute ago /bin/sh -c apk add --no-cache wget && wget h… 9.67MB 
6d1ef012b567 16 months ago /bin/sh -c #(nop) CMD ["/bin/sh"] 0B 
<missing> 16 months ago /bin/sh -c #(nop) ADD file:aa17928040e31624c… 4.21MB

가독성과 이미지의 트레이드 오프
- &&나 백슬래시를 만힝 사용해야 하며 빌드 스타일에 따라 cd 명령을 자주 사용하게 되므로 Dockerfile의 가독성을 해치게 된다.
- 이미지 빌드를 시행착오와 함께 반복해야 하는 경우라면 중간 빌드를 재활용하는 이점을 누릴 수가 없다.
- 이는 불가피하게 개발 효율을 떨어뜨리므로 개발 과정에서는 각 명령을 별도로 RUN 인스트럭션으로 실행한다.
- 빌드 내용이 고정된 다음에 RUN 인스트럭션의 실행 횟수를 줄이면 된다.
- 무리하게 모든 경우에 적용하지 않는 것이 좋다.
- 이 방법이 유용한 경우는 수 MB 이상의 파일으 자주 다루는 과정이 빌드에 포함되는 경우다.
- 중간 레이어 개수 자체가 적은 경우에는 굳이 적용할 필요가 없다.

4. 멀티 스테이지 빌드

빌드 부산물을 완전히 제가할 수 없다는 한계의 대책 : 멀티 스테이지 빌드

빌드 컨테이너와 실행 컨테이너의 분리

적용 전

FROM golang:1.13

WORKDIR /
ENV GOPATH /go

COPY . /go/src/github.com/gihyodocker/todoapi
RUN go get github.com/go-sql-driver/mysql
RUN go get gopkg.in/gorp.v1
RUN cd /go/src/github.com/gihyodocker/todoapi && go build -o bin/todoapi cmd/main.go
RUN cd /go/src/github.com/gihyodocker/todoapi && cp bin/todoapi /usr/local/bin/

CMD ["todoapi"]

적용 후

FROM golang:1.13 AS build

WORKDIR /
ENV GOPATH /go

COPY . /go/src/github.com/gihyodocker/todoapi
RUN go get github.com/go-sql-driver/mysql
RUN go get gopkg.in/gorp.v1
RUN cd /go/src/github.com/gihyodocker/todoapi && go build -o bin/todoapi cmd/main.go

FROM apline:3.7

COPY --from=build /go/src/github.com/gihyodocker/todoapi && cp bin/todoapi /usr/local/bin/
CMD ["todoapi"]

빌드 산출물을 다른 컨테이너로 복사할 수 있다.
실행 컨테이너에 불필요한 파일을 전혀 포함하지 않고 가벼운 이미지를 만들 수 있다.
Dockerfile의 가독성을 유지하면서도 이미지의 크기를 억제할 수 있다.
장점
- 이미지 크기 감소뿐만 아니라 이식성에도 도움을 준다.
- 하나의 Dockerfile 안에서 컨테이너 간에 파일을 주고 받기 때문에 도커 호스트와 상관 없이 항상 같은 최종 결과물을 얻을 수 있다.

[2019] 실패율

Sun, 24 Nov 2019 00:00:00 +0000

문제 출처

문제 설명
1. 실패율 = A / B
  - A : 스테이지에 도달했으나 클리어하지 못한 플레이어 수
  - B : 스테이지에 도달한 플레이어 수
2. B가 0인 경우 실패율은 0으로 정의한다.
3. 실패율이 높은 스테이지부터 내림차순으로 정렬된 배열을 리턴한다.
문제 풀이

CH10. 다양한 도커 활용 방법

Fri, 03 Jul 2020 00:00:00 +0000

팀 개발에서 개발환경을 통일
명령행 도구를 통한 도커 컨테이너 사용법
도커를 이용한 부하 테스트 방법

1. 팀 개발에서 개발 환경 통일하기

INTRO
- 어플리케이션 및 미들웨어의 동작을 환경 변수로 제어하는 방법으로 도커 이미지의 추상 수준을 높일 수 있다.
- 다양한 환경에 배포하기 쉽게 할 수 있다.
- 개발 환경을 공유하고 통일하는 방법으로 이용할 수 있다.
소프트웨어 및 도구 통일
- 호스에서 격리된 환경에 필요한 도구를 갖춘 도커 컨테이너를 공통 개발 환경으로 사용하는 것이 바람직하다.
- 예시
  - MySQL이나 Redis 같은 데이터스토어를 사용한는 프로젝트는 이 외 데이터스토어를 조작하기 위한 클라이언트 도구가 필요하다.
  - 고성능 MySQL 클라이언트인 mycli 혹은 Redis 클라이언트인 redis-tools를 팀의 표준 도구로 지정하면 다음과 같은 도커 이미지를 공통 개발 환경으로 사용할 수 있다.
  - Dockerfile
```
FROM ubuntu:16.04

RUN apt -y update
RUN apt -y install net-tools \
iproute2 \
inetutils-ping \
tcpdump \
mycli \
redis-tools
```
  - 이미지 빌드 및 컨테이너 생성(docker)
```
$ docker image build -t ch10/workspace:latest .
$ docker container run --rm -it --name workspace ch10/workspace:latest bash
```
  - 쿠버네티스에서 workspace 생성
```
$ kubectl run -i --rm --tty workspace --image=ch10/workspace:latest --restart=Never -- bash -il
```
- ‘하나의 컨테이너에 하나의 관심사’라는 도커의 원칙에는 어긋나지만, 어플리케이션 배포 용도가 아니므로 괜찮다.
개발 환경은 집단지성의 결과
- 팀 내 표준 개발 환경을 도커 컨테이너 형태로 제공하는 것은 매우 의미 있는 일이다.
- 장점
  - 일단 개발 환경을 공유하면 여러 개발자가 수고를 덜 수 있다.
  - 각자가 가진 노하우를 공유하고 이렇게 형성한 집단지성을 업무에 활용이 가능하다.
  - 환경 구성 절차를 Dockerfile 형태의 프로그램으로 작성할 수 있다.
  - 신속하게 컨테이너를 실행하고 폐기할 수 있기 때문에 개발 환경에 베스트 프랙티스를 지속해서 반영할 수 있다.

2. 도커 컨테이너에서 명령행 도구(CLI) 사용하기

Dockerfile의 문법 검사를 도와주는 명령행 도구인 hadolint를 도커 컨테이너 형태로 실행한다.
- Dockerfile
```
FROM alpine

RUN echo "docker!!"
```
- 검사
```
$ docker container run --rm -i hadolint/hadolint < Dockerfile
/dev/stdin:1 DL3006 Always tag the version of an image explicitly
```
- 이미지 버전 생략의 경고인 DL3006이 발생했다.
- hadolint와 같은 도구를 처음 사용하더라도 추가적인 수고는 들지 않는다.
- -i 옵션 : Dockerfile을 리다이렉트로 전달하기 위해서 사용하였다.
- -v 옵션이 자주 같이 사용된다.
- 명령행 도구도 호스트에 설치하지 않고 도커 컨테이너 형태로 사용할 수 있다.
이미지에서 명령행 도구 버전 변경하기
- 명령행 도구를 사용할 때 중요함 점이 도구의 버전을 관리하는 것이다.
- 명령행 도구를 편리하게 사용하려면도구 버전을 업데이트하거나 특정 버전으로 고정하는 작업이 꼭 필요하다.
- 명령행 도구를 사용하면서 다음과 같은 필요가 발생할 수 있다.
  - 항상 최신 버전(보안 패치가 모두 적용된)을 사용할 수 있다.
  - 버전이 바뀔 때마다 변경 사항이 많은 도구라서 특정 버전을 고정적으로 사용하고 싶다.
- 명령해 도구의 도커 이미지를 버전 별로 만들어 두는 것이 좋다.
  - 언제든지 필요한 버전의 명령행 도구를 사용할 수 있다.
- 예제 : jq를 도커 컨테이너로 실행
  - Dockerfile
```
FROM alpine:3.7

RUN apk add --no-cache --virtual=build-devs wget && \
wget https://github.com/stedolan/jq/releases/download/jq-1.5/jq-linux64 && \
mv jq-linux64 /usr/local/bin/jq && \
chmod +x /usr/local/bin/jq && \
apk del build-devs

ENTRYPOINT ["/usr/local/bin/jq", "-C"]
CMD [""]
```
  - 이미지 빌드 및 태그 변경
```
$ docker image build -t ch10/jq:latest .
$ docker image tag ch10/jq:latest ch10/jq:1.5
```
  - 테스트
```
$ echo '{"version":100}' | jq '.version
$ echo '{"version":100}' | docker container run -i --rm ch10/jq:1.5 '.version
```
  - alias로 docker container run -i --rm ch10/jq:1.5를 jq1.5로 등록하여 사용할 수 있다.
```
$ alias jq1.5='docker container run -i --rm ch10/jq:1.5'
$ echo '{"version":100}' | jq1.5 '.version'
```
도커 컨테이너로 셸 스크립트 실행하기
- 배포 및 운영과 관련된 내용을 포함하는 셸 스크립트를 다양한 도구를 이용해 실행하는 경우도 많다.
- 여러 도구를 한꺼번에 다루거나 처리 과정을 코드로 옮겨 작업할 수 있다면 작업 효율이 향상시킬 수 있을 것이다.
- 스크립트가 자신이 의존하는 도구나 라이브러리의 버전을 업데이트하면서 또 다른 도구의 동작이 달라지는 경우도 있다.
- 셸 스크립트가 가볍고 편리하기는 하나 모든 환경에서 같은 동작을 보장하려면 여러모로 신경 써야 한다.
- 환경 차이에서 오는 불필요한 트러블을 방지하려면 스크립트와 스크립트가 의존하는 도구를 함께 도커 컨테이너에 격리해 놓으면 된다.
- 예제 : 표준 출력으로 출력된 JSON 문서에서 지정한 속성의 속성값을 추출한다.
  - show-attr.sh 작성(따로 실행 권한(+x)을 주지 않아도 된다.)
```
#!/bin/bash
ATTR=$1
if [ "$ATTR" = "" ]; then
 echo "required attribute name argument" 1>&2
 exit 1
fi

echo '{
 "id": 100,
 "username": "gihyo",
 "comment": "I like Alpine Linux"
}' | jq -r ".$ATTR"
```
  - Dockerfile 작성
```
FROM alpine:3.7

RUN apk add --no-cache --virtual=build-devs wget && \
wget https://github.com/stedolan/jq/releases/download/jq-1.5/jq-linux64 && \
mv jq-linux64 /usr/local/bin/jq && \
chmod +x /usr/local/bin/jq && \
apk del build-devs

COPY show-attr.sh /usr/local/bin/

ENTRYPOINT ["sh", "/usr/local/bin/show-attr.sh"]
CMD [""]
```
  - 빌드 및 실행
```
$ docker image build -t ch10/show-attr:latest .
$ docker container run --rm ch10/show-attr:latest username
```
마무리
- 컨테이너 이전의 셸 스크립트는 스크립트가 의존하는 도구나 라이브러리의 관리 문제와 스크립트만 봐서는 환경 구축 시에 알아야 할 내용을 파악하기 어렵다.
- 컨테이너를 이용해 스크립트와 그 실행 환경 자체를 분리하면 이식성 확보는 문론이고 Dockerfile 안에 스크립트가 의존하는 도구 및 라이브러리가 한눈에 정리된다.
- CI/CD 단계에서 스크립트를 포함하는 컨테이너 자체를 테스트할 수도 있다.

3. 부하 테스트

테스트 환경 구축

[2019] 후보키

Sun, 24 Nov 2019 18:15:02 +0900

문제 출처

문제 설명
1. 후보키 : 유일성과 최소성을 만족하는 것을 후보키(Candidate Key)라고 한다.
2. 테이블이 주어졌을 때 후보키의 최대 갯수를 구한다.
유일성(uniqueness)
릴레이션에 있는 모든 튜플에 대해 유일하게 식별되어야 한다.

부록 A : 보안

Tue, 14 Jul 2020 00:00:00 +0000

1. 공개된 도커 이미지의 안전성

INTRO
- 공개적인 생태계의 특성상 악의적인 이미지가 포함될 가능성을 배제할 수 없다.
- 안전한 도커 이미지를 판단하는 기준을 파악하고 위험한 이미지를 가려내는 안목이 필요하다.
도커 허브
- 도커의 기본적인 레지스트리이다.
- docker search 명령으로 도커 허브에 등록된 이미지를 검색할 수 있다.
  - 정렬
    - 리포지토리의 스타 수(인기)
    - pull 횟수
    - OFFICIAL 항목 : [OK]라면 도커 허브의 공식 리포지토리
- OFFICIAL
  - 해당 소프트웨어의 전문가나 보안 전문가와 협조해 이미지의 품질을 담보하기 위한 리뷰를 거친 것
  - 일정 수준의 보안성을 확보했다고 할 수 있다.
Quay.io
- CoreOS에서 운영하는 Quay.io
- 사설 리포지토리 및 자동 빌드(automated build)를 지원한다.
- 조직 관련 기능으로 팀 구성 및 롤 설정 기능을 제공하므로 도커 허브보다 훨씬 충실하게 팀 개발을 뒷바침할 수 있다.
- Quay.io는 취약점 정보 데이터베이스이 CVE 정보를 기초로 설치된 패키지를 통해 취약점 포함 여부를 확인한다.
Outro
- 도커 허브에서 제공하는 공식 이미지나 Quay.io의 취약점 검사 등은 이미지의 안전성을 평가할 수 있는 중요한 지표이다.
- 이 지표가 완벽한 것은 아니다.
- 계획 중인 유즈케이스에 따라 어떤 위험이 따르는지 직접 확인하는 것이 중요하다.

2. 안전한 도커 이미지와 도커 운영 체제 꾸리기

INTRO
- 각 개발자가 안전한 도커 이미지를 만들고 보안 위험이 발생하지 않도록 운영 체계를 구축할 필요가 있다.
Docker Bench for Security
- 운영 환경에서 도커를 적용할 때 반드시 따라야 할 베스트 프랙티스의 준수 여부를 검사하는 도구
- 도커 컨테이너의 취약점을 발견하는 데 유용하다.
- docker/docker-bench-security 이미지로 제공된다.
- 도커 호스트에서 실행
```
$ docker container run -it --net host --pid host --userns host \
--cap-add audit_control \
-e DOCKER_CONTENT_TRUST=1 \
-v /var/lib:/var/lib \
-v /var/run/docker.sock:/var/run/docker.sock \
-v /usr/lib/systemd:/usr/lib/systemd \
-v /etc:/etc \
--label docker-bench_security \
docker/docker-bench-security
```
- 실행 중인 컨테이너뿐만 아니라 도커 환경 전반에 걸친 취약점을 검사한다.
- Docker daemon configuration : 도커 데몬의 설정을 검사
  - TLS/SSL이 적용되지 않은 비보안 레지스트리를 사용하고 있다면 2.4 - Ensure insecure registries are not used 경고를 띄운다.
- Container Images and Build File : Dockerfile에 대한 검사
  - 컨테이너 안에 어플리케이션 실행만을 위한 별도의 유저가 없다면 4.1 - Ensure a user for the container has been created 경고를 띄운다.
- 운영 중 노출되기 쉬운 취약점을 탐지할 수 있으며 이 취약점을 해결하기 위한 베스트 프랙티스를 제시해 준다.
- 탐지된 취약점을 충분히 이해하는 것이 중요하다.
컨테이너에 파일을 추가하면서 발생하는 위험
- Dockerfile로 컨테이너에 파일을 추가하는 인스트럭션 : ADD, COPY
  - COPY
    - 호스트에서 파일이나 디렉터리를 복사해오는 기능을 수행
  - ADD
    - 지정한 URL에서 파일을 내려받아 추가할 수 있다.
    - 압축 파일을 자동으로 해제하는 기능이 있다.
  - 두 인스트럭션은 적절히 용도를 나눠 사용하지 않으면 취약점이 생길 수 있다.
- URL에서 내려받은 파일이 항상 안전하다는 보장이 없다.
  - 파일이 웹 사이트 소유자에 의해 변경될 수 있다.
  - 악의를 품은 제삼자가 파일을 변조했을 수 있다.
  - 이미지가 빌드될 때마다 결과물도 달라질 것이므로 항등성도 담보할 수 없다.
- ADD 인스트럭션을 사용하려면 추가하려는 파일의 안전성을 먼저 검증해야 한다.
- Dockerfile에는 ADD 인스트럭션 대신 COPY 인스트럭션을 사용하는 버릇을 들이는 것이 좋다.
- RUN
  - wget이나 curl을 이용해 추가하는 방법도 있다.
  - 호스트로부터 파일을 추가하는 게 아니라 파일 추가 과정 자체를 컨테이너 안으로 국한 시킬 수 있기 때문에 이식성이 뛰어나다.
  - ADD 인스트럭션과 마찬가지의 취약점을 가질 수 있다는 점을 이해하고 사용해야 한다.
- 예제 : 프로비저닝 도구 Terraform
  - Terraform은 실행 파일을 포함하는 zip 파일과 함께 SHA256으로 생성한 체크섬 정보를 제공한다.
  - 적합성 검사 Dockerfile
```
FROM alpine:3.7

ENV VERSION=0.11.5

RUN apk --no-cache add --virtual=build-devs curl gnupg

# terraform과 배포 파일 체크섬 정보를 받음
ADD https://releases.hashicorp.com/terraform/$VERSION/terraform_${VERSION}_linux__amd64.zip .
ADD https://releases.hashicorp.com/terraform/$VERSION/terraform_${VERSION}_SHA256SUMS .
ADD https://releases.hashicorp.com/terraform/$VERSION/terraform_${VERSION}_SHA256.sig .

# Keybase에 공개된 Hashicorp사의 PGP 공개키 임포트
RUN curl https://keybase.io/hashicorp/pgp_keys.asc | gpg --import

# 체크섬의 전자서명 검증
RUN gpg --verify terraform_${VERSION}_SHA256SUMS.sig terraform_${VERSION}_SHA256SUMS

# 압축 파일의 체크섬 검증
RUN cat terraform_${VERSION}_SHA256SUMS | grep linux_amd64 | sha256sum -cs
RUN unzip terraform_${VERSION}_linux_amd64.zip
RUN mv terraform /usr/local/bin/
RUN terraform -v
```
  - Terraform을 개발한 Hashicorp는 Keybase에 PGP 공개키를 공개 중이다.
  - 체크섬 정보의 서명을 검증한다.
  - 서명이 확인되면 이 체크섬 정보를 zip 파일로부터 계산한 체크섬과 비교하는 방법으로 zip 파일의 정합성을 검증할 수 있다.
  - 체크섬 정보가 일치하지 않는다면 빌드는 실패 처리된다.
  - 외부로 공개되는 Dockerfile에 이런 방식으로 검증 로직을 추가하면 이미지의 신뢰성을 향상시킬 수 있다.
적절한 접근 제어
- 컨테이너를 침입으로부터 보호
  - 컨테이너 중심의 개발 및 운영에서 가장 중요한 것은 외부인의 컨테이너 침입을 방지하는 것이다.
  - 대책
    - root로 로그인 금지.
    - AWS의 보안 그룹, GCP의 방화벽을 적절히 설정하고 도커 호스트에 대한 접근 제어.
    - VPN 적용 및 내부망 접근 제한.
- /var/run/docker.sock의 컨테이너와의 공유 금지
  - 도커는 유닉스 도메인 소켓 /var/run/docker.sock을 -v 옵션으로 마운트하고 이를 이용해 원격지의 도커 데몬에 접근한다.
  - 이 소켓에 접근을 허용하면 컨테이너 생성 등의 작업을 원하는 대로 지시할 수 있다.
  - /var/run/docker.sock을 사용하는 이미지의 사용은 원칙적으로 금해야 한다.
  - 배포 중인 Dockerfile을 살펴보고 보호 대책을 마련해야 한다.
  - 특별한 사정이 없다면 호스트의 /var/run/docker.sock을 컨테이너 마운트하는 일은 하지 않는 것이 좋다.
- 컨테이너 어플리케이션 실행용 사용자 추가
  - 도커 컨테이너 안에서 어플리케이션을 실행하는 기본 사용자 : root
  - 도커 이미지를 빌드하는 과정이라면 root 권한을 갖는 쪽이 편하다. 하지만 이것이 보안에 큰 구멍이 될 수 있다.
  - 도커는 호스트의 리소스를 컨테이너에서 공유하는 기술적 특징을 갖는다. 사용자 UID도 예외가 아니다.
  - 모종의 경로를 통해 컨테이너에 침입했다면 사실상 호스트의 root 권한을 탈취한 것과 같다.
  - 이런 문제를 방지하기 위해서 useradd 명령으로 어플리케이션 실행용 사용자를 생성하고 USER 인스트럭션에서 해당 사용자를 지정하면 된다.
```
FROM golang:1.9

RUN mkdir /echo
COPY main.go /echo/

RUN useradd gihyo
USER gihyo

CMD ["go", "run", "/echo/main.go"]
```
    - 컨테이너를 실행해 보면 gihyo 상용자가 어플리케이션을 실행하고 있음을 알 수 있다.
기밀정보 취급
- 환경 변수를 이용하는 방법
  - 컨테이너의 환경 변수 값은 너무 간단히 노출된다.
    - env 명령만 사용할 수 있다면 모든 환경 변수 값을 볼 수 있다.
    - docker container inspect <컨테이너 ID>명령도 같다.
  - 환경 변수 방식을 적용하려면 권한 없는 제삼자가 도커 호스트나 도커 데몬을 조작할 수 없도록 적절한 접근 통제 정책을 먼저 실시해야 한다.
  - 제삼자에게 기밀정보가 유출되어도 상관없도록 기밀정보 자체를 암호화하고 어플리케이션 안에서만 복호화할 수 있도록 구현하는 것도 좋은 방법이다.
- 기밀정보를 외부에서 받아오는 방법
  - 컨테이너 안에 있는 어플리케이션이 직접 외부에서 기밀정보를 받아오는 방법이 있다.
  - 컨테이너에 접근하더라도 사용자는 아무런 기밀정보를 볼 수 없으며 어플리케이션이 원격지에 위치한 기밀정보를 참조해오는 방식이다.
  - 이 기밀정보는 기계만 읽을 수 있는 형태이므로 기밀정보를 받아오는 통신 내용이 암호화되고 적절한 접근 통제만 되면 극히 안전한 방법이다.
  - 예시
    - 아마존 S3에 저장된 기밀정보에 접근하기 위해 IAM을 이용하는 방법이 있다.
    - Hashicorp가 개발한 Vault가 있다.
      - 기밀정보를 저장하는 도구.
      - 어플리케이션을 기밀정보를 전달받는 데이터베이스로 활용할 수 있다.
      - 암호화 기능, 기밀정보 열람 로그 기능, 무효화 기능 등을 제공한다.

[2019] 매칭 점수

Sun, 24 Nov 2019 18:15:23 +0900

문제 출처

문제 설명
1. 한 웹페이지에 대해서 기본점수, 외부 링크 수, 링크점수, 매칭점수를 구할 수 있다.
2. 기본점수 : 텍스트 중에 검색어가 등장한 횟수(대소문자 무시)
3. 외부 링크 수 : 다른 외부 페이지로 연결된 링크의 개수
4. 링크점수 : ( 해당 웹페이지로 걸린 다른 웹페이지의 기본점수 ) / ( 외부링크 수) 의 합
5. 매칭점수 : 기본점수 + 링크점수
6. 매칭점수가 높은 웹페이지의 번호를 리턴한다.
7. 매칭점수가 같은 웹페이지가 여러 개라면 그중 번호가 가장 작은 것을 구한다.
입력 예시 : ["<html lang=\"ko\" xml:lang=\"ko\" xmlns=\"http://www.w3.org/1999/xhtml\">\n<head>\n <meta charset=\"utf-8\">\n <meta property=\"og:url\" content=\"https://careers.kakao.com/interview/list\"/>\n</head> \n<body>\n<a href=\"https://programmers.co.kr/learn/courses/4673\"></a>#!MuziMuzi!)jayg07con&&\n\n</body>\n</html>", "<html lang=\"ko\" xml:lang=\"ko\" xmlns=\"http://www.w3.org/1999/xhtml\">\n<head>\n <meta charset=\"utf-8\">\n <meta property=\"og:url\" content=\"https://www.kakaocorp.com\"/>\n</head> \n<body>\ncon%\tmuzI92apeach&2<a href=\"https://hashcode.co.kr/tos\"></a>\n\n\t^\n</body>\n</html>"]

부록 B : 도커로 개발을 지원하는 도구 및 서비스

Fri, 10 Jul 2020 00:00:00 +0000

1. 인하우스 도커 레지스트리 구축

도커 이미지를 보관하기에는 도커 허브나 Quay.io 같은 퍼블릭 레지스트리 서비스를 이용하는 것이 편리하다.
퍼블릭 레지스트리를 사용 불가한 경우
- 퍼블릭 레지스트리의 지나치게 긴 응답 시간
- 보안 측면의 문제
  - 운영 환경에 배포하기 위해 개발한 어플리케이션 이미지를 퍼블릭 레지스트리에 저장할 수는 없다.
인하우스 도커 레지스트리
- 레지스트리를 직접 구축하여 어떤 보안 정책이라도 만족시킬 수 있다.
- 컨테이너를 배포하는 호스트와 가까이 도커 레지스트리가 위치할 것이므로 배포 속도 또한 개선할 수 있다.
Registry(Docker Distribution)
- 도커에서 인하우스 도커 레지스트리를 구축할 수 있도록 배포하는 도구
- Docker Distribution과 함께 제공된다.
- 오픈소스 소프트웨어이며 도커 컨테이너 형태로 실행할 수 있으므로 도커 호스트 역할을 할 운영 체제만 있으면 레지스트리 운영이 가능하다.
- 3장의 docker swarm을 구축할 때 사용했다.
구축
- Registry 설치(서버) : ubuntu 16.x
  - /etc/systemd/system/docker-container@registry.service
```
[Unit]
Descriptioni=Registry
Requires=docker.service
After=docker.service

[Service]
Restart=always
ExecStart=/usr/bin/docker container run --rm --name registry -p 5000:5000 library/registry

[Install]
WantedBy=multi-user.target
```
  - 서비스로 활성화 한다.
```
$ systemctl enable docker-container@registry.service
$ systemctl start docker-container@registry.service
```
  - 곧 registry 컨테이너가 실행된다.
- Registry에 이미지 등록하기
  - Registry는 HTTP API를 제공한다.
```
$ curl http://localhost:5000/v2/_catalog
```
  - 태그를 부여해 기존 알파인 리눅스 이미지를 Registry에 등록한다.
```
$ docker image pull alpine:3.7
$ docker image tag alpine:3.7 localhost:5000/alpine:3.7
$ docker image push localhost:5000/alpine:3.7
```
- Registry에서 이미지 내려받기
  - Registry 컨테이너를 실행한 호스트에서 localhost:5000으로 접근하면 된다.
  - 그 외 호스트에서 Registry에서 접근하려면 도메인 부분을 다른 호스트에서 참조 가능한 IP 주소나 호스트명으로 바꿔야 한다.
  - docker image pull 명령은 기본적으로 HTTPS를 통해 레지스트리에 접근하기 때문에 Registry 역시 HTTPS를 활성화 하지 않으면 오류가 발생한다.
  - 외부에서 접근이 불가능한 내부 네트워크 안에서만 이미지가 전송된다면 굳이 HTTPS를 적용할 필요가 없다.
    - docker image pull 명령을 실행하는 쪽의 /etc/docker/daemon.json 파일에 HTTP 통신을 허용한다.
    - Insecure registries에 값을 추가한다.

2. 도커와 CI/CD 서비스 연동

도커를 사용한 어플리케이션 개발 과정
- 구현 - 단위 테스트 - 어플리케이션 빌드 - 도커 이미지 빌드 - 도커 레지스트리 등록
- 위 과정의 반복
- 이 과정을 수작업으로 진행하면 실수가 발생하기 쉽다.
- CI/CD 서비스에 이 과정을 맡기면 실수를 줄이고 시간도 적야할 수 있으므로 적절한 자동화 도입이 매우 중요하다.
  - CI : Continuous Integrate : 지속적 통합
  - CD : Continuous (Deploy | Delivery) : 지속적 배포
- CI/CD 서비스의 예시 : Jenkins, CircleCI

CircleCI

INTRO
- SaaS(Software As A Service) 형태로 제공되는 CI/CD 서비스
- 빌드 설정 역시 yaml 포맷으로 기술할 수 있다.
- 이번에 다루는 내용은 CircleCI와 github를 사용한다.
github 계정으로 OAuth 인증을 거쳐 가입하고 로그인한다.

프로젝트 추가

github에 리포지토리를 새로 추가하고 내용으로 Dockerfile과 main.py를 생성한다.

Dockerfile

FROM python:3.6-alpine

WORKDIR /app
COPY main.py /app/main.py

CMD ["python", "main.py"]

main.py

# -*- coding: utf-8 -*-
import socket

# simple-echo-server
def serve(host='0.0.0.0', port=8080):
 with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:
 s.bind((host, port))
 s.listen()
 while True:
 conn, addr = s.accept()
 with conn:
 print('connected by', addr)
 if conn.recv(1024):
 conn.sendall(b'hello python!!')

if __name__ == '__main__':
 serve()

프로젝트가 추가되면 대상 저장소에 푸시가 일어날 때마다 웹훅이 CircleCI의 CI/CD 잡을 시작하게 한다.
깃허브 조직 저장소를 추가하려면 깃 허브 설정에서 CircleCI의 Organization access 권한을 부여해야 한다.

빌드 설정 파일 작성

python 저장소를 이용해 도커 이미지 빌드에 이르는 과정을 설정한다.

.circleci/config.yml

version: 2.1
jobs:
 build:
 # CircleCI 컨테이너의 작업 디렉토리
 working_directory: /app
 # 잡을 실행하는 컨테이너의 도커 이미지
 docker:
 -  image: python:3.6-alpine
 steps:
 -  checkout  # 저장소에서 소스코드를 체크아웃
 -  persist_to_workspace: # workspace를 후속 잡에서 사용할 수 있도록 유지
 root: .
 paths:
 -  .
 docker_build_push:
 working_directory: /app
 docker:
 - image: docker:18.05.0-ce-dind # docker 명령을 사용할 수 있는 컨테이너
 steps:
 -  attach_workspace: # 저장해둔 workspace를 배치
 at: .
 -  setup_remote_docker: # docker image build를 수행할 데몬 준비
 version: 18.05.0-ce
 -  run: # 도커 이미지 빌드
 name: docker image build
 command: docker image build -t joonstudydocker/echo-python:latest .
 -  run: # 빌드된 이미지 확인
 name : docker image ls
 command: docker image ls
 -  run: # 도커 허브 로그인
 name: docker login
 command: docker login -u $DOCKER_USER -p $DOCKER_PASS # 프로젝트 설정에서 환경 변수를 저장할 수 있다.
 -  run: # latest 이미지를 도커 허브에 등록
 name: release latest
 command: docker image push joonstudydocker/echo-python:latest
workflows:
 version: 2
 build_and_push:
 jobs: # workflows로 실행할 잡을 열거
 -  build
 -  docker_build_push:
 requires: # build 잡 다음에 실행
 -  build
 # master 브랜치인 경우에만 실행
 # 다른 브랜치에서도 실행하려면 주석 처리하거나 제거
 filters: 
 branches:
 only: master

CircleCI와 저장소를 연동하여 어플리케이션 테스트 및 도커 이미지 빌드와 등록을 대신해주는 CI/CD 환경을 구축하였다.

참고

docker login 오류 - ubuntu16.x

$ sudo apt install gnupg2 pass 
$ gpg2 --full-generate-key
$ gpg2 -k
$ pass init "whatever key id you have"

3. ECS에서 AWS Fargate를 이용한 컨테이너 오케스트레이션

ECS - Elastic Container Service
- AWS는 지금까지 독자적인 컨테이너 오케스트레이션 서비스 ECS를 제공해왔다.
- ESC는 서버 여러대를 이용해 컨테이너 오케스트레이션을 구현하는 방식이다.
- ALB라는 AWS 서비스와 매끄럽게 연동된다.
  - ALB - Application Load Balancer
- ECS는 최초 도입이 쿠버네티스보다 쉽기 때문에 프로젝트 규모와 무관하게 널리 사용된다.
  - 넷플릭스에서 대규모로 운영한 실적이 있다.
AWS Fargate
- 개발자가 서버나 클러스터를 직접 관리하지 않고 컨테이너를 실행하는 기술
- ECS나 EKS에서는 서버관리, 클러스터 프로비저닝 등을 담당하는 서비스이다.
- 컨테이너 오케스트레이션부터 서버 및 클러스터 관리에 이르기까지 가장 손이 많이 가는 작업을 제거했다는 점에서 획기적이라 할 수 있다.
- AWS Fargate는 AWS Lambda의 뒤를 잇는 차세대 서버리스 기술로서도 주목받고 있다.
  - Lambda는 장시간 실행되는 배치 어플리케이션에는 적합하지 않은데, ECS는 이러한 약점을 보완할 수 있다.
  - AWS Fargate는 서버 인스턴스를 신경 쓰지 않고도 간단히 컨테이너 오케스트레이션을 실현할 수 있으므로 컨테이너 기술 및 서버리스 기술 양쪽에서 새로운 트랜드가 될 것이다.
Fargate로 ECS 클러스터 구축
- AWS console에서 ECS를 선택하면 Fargate 마법사 화면이 나타난다.
- 시작을 눌러서 설정을 시작한다.
- 1단계 : 컨테이너 및 작업
  - nginx를 선택한다.
- 2단계 : 서비스
  - 로드 밸런서 유형을 Application Load Balancer를 선택한다.
- 3단계 : 클러스터
  - Cluster 이름을 설정한다.
  - 필자는 joon으로 하겠다.
- 4단계 : 검토
  - 지금까지의 내용을 검토한 뒤에 생성을 누른다.
- 생성 뒤 확인
  - ECS 관련 리소스가 수 분 만에 생성된다.
- 생성된 nginx에 접속
  - 생성한 뒤 로드 밸러서를 확인한다.
  - ECS 클러스터에 배포된 컨테이너는 모두 ALB라는 로드 밸런서를 통해 접근하므로 지금 만든 ALB의 DNS name을 복사한다.
  - 웹 브라우저에서 ‘http://복사한도메인’에 접근하면 nginx의 welcome 화면을 볼 수 있다.
ECS를 조작해 어플리케이션 배포하기
- ECS 리소스
  - (작음) Container Definition - Task Definition - Service - Cluster (큼)
  - Container Definition : 배포되는 각 컨테이너의 정의
  - Task Definition : 컨테이너의 집합인 Task의 정의
  - 쿠버네티스 파드의 개념이 두 단계로 나뉘어 있다고 생각하면 된다.
- Task Definition 생성
  - 작업 정의 - 새로운 작업 정의 작성
  - FARGATE를 선택하고 다음을 누른다.
  - 테스크 정의 이름은 echo-task로 한다.
  - 네트워크 모드는 awsvpc를 선택하여 내부 IP(private)만 부여한다.
  - CPU 리소스
    - memory : 0.5GB
    - CPU : 0.25vCPU
  - 컨테이너 정의
    - echo
      - 이름 : echo
      - 이미지 : stormcat24/echo:latest
      - 포트 맵핑 : 8080
    - nginx
      - 이름 : nginx
      - 이미지 : stormcat24/nginx-proxy:latest
      - 포트 맵핑 : 80
      - 환경변수
        
        BACKEND_HOST : value : localhost:8080
- 서비스 수정
  - 새 배포 적용을 체크한다.
  - 작업 개수는 1로 한다.
  - 이후 화면은 수정 없이 다음을 클릭한다.
  - Service 수정이 끝나면 이미 배포된 태스크가 정지되며 echo-task:1 태스크가 하나 배포된다.
  - 태스크 상세 정보를 확인하면 echo와 nginx 컨테이너를 포함한 태스크가 배포된 것을 알 수 있다.
- ALB와 대상 그룹
  - Service는 ABL와 연동해 외부로부터 접근할 수 있다.
  - RUNNING 상태가 된 태스크는 ALB가 확인한 헬스 체크 결과가 healthy로 나와야 비로소 트래픽이 전달된다.
OUTRO
- 도커로 운영 환경을 꾸린다 해도 서버나 클러스터를 계속 신경써야 할 것이다.
- 그러나 Fargate를 사용하면 한 번 설정하면 그 이후에는 자동으로 제어된다.
- 이는 도커를 적용한 운영 환경을 쾌적하게 해주는 기술이다.

[2019] 무지의 먹방 라이브

Sun, 24 Nov 2019 18:15:07 +0900

문제 출처

문제 설명
1. 회전판에 먹어야 할 N개의 음식이 있다.
2. 무지는 1번 음식부터 먹기 시작하며, 회전판은 번호가 증가하는 순서대로 음식을 무지 앞으로 가져다 놓는다.
3. 무지는 음식 하나를 1초 동안 섭취한 후 남은 음식은 그대로 두고, 다음 음식을 섭취한다.
4. 무지가 먹방을 시작한 지 K초 후에 네트워크 장애로 인해 방송이 잠시 중단되었다가 정상화 후 다시 방송을 이어갈 때, 몇 번 음식부터 섭취해야하는지 알고자 한다.
5. 더 이상 섭취할 음식이 없다면 -1 을 반환한다.
문제 풀이

부록 C : 주요 명령어 정리

Fri, 10 Jul 2020 00:00:00 +0000

1. 도커 명령어

$ docker image build [options] (Dockerfile경로 | URL)
- Dockerfile로부터 도커 이미지를 빌드
$ docker search [options] 키워드
- 도커 허브에서 제공되는 도커 이미지를 검색
$ docker image pull [options] 리포지토리명[:태그명]
- 도커 레지스트리에서 도커 이미지를 다운로드
$ docker image ls [options] [리포지토리명[:태그명]]
- 해당 도커 호스트가 보유한 도커 이미지의 목록을 출력
$ docker image tag 이미지원래이름[:태그] 이미지새이름[:태그]
- 도커 이미지 태그를 생성
$ docker image push [options] 리포지토리명[:태그명]
- 도커 레지스트리에 도커 이미지를 전송해 등록
$ docker container run [options] 이미지명[:태그명] [명령] [명령인자 ...]
- 도커 컨테이너를 새로 실행
$ docker container ls [options]
- dockerd가 보유한 컨테이너 목록 출력
$ docker container stop [options] (컨테이너ID | 컨테이너명)
- 실행중인 컨테이너를 정지
$ docker container restart [options] (컨테이너ID | 컨테이너명)
- 정지한 컨테이너를 다시 실행
$ docker container rm [options] (컨테이너ID | 컨테이너명)
- 컨테이너를 디스크에서 삭제
$ docker container logs [options] (컨테이너ID | 컨테이너명)
- 컨테이너의 로그(표준 출력)를 화면에 출력
$ docker container exec -it [options] (컨테이너ID | 컨테이너명) 컨테이너에서_실행할_명령
- 실행 중인 컨테이너에서 명령어를 실행
$ docker container cp [options] (컨테이너ID | 컨테이너명):원본파일 대상파일
- 컨테이너에서 호스트로 파일 및 디렉토리 복사
$ docker container cp [options] 호스트_원본파일 (컨테이너ID | 컨테이너명):대상파일
- 호스트에서 컨테이너로 파일 및 디렉토리 복사
$ docker container prune [options]
- 정지 상태인 모든 컨테이너를 디스크에서 삭제
$ docker image prune [options]
- 사용하지 않는 모든 도커 이미지를 디스크에서 삭제
$ docker system prune [options]
- 사용하지 않는 컨테이너 및 이미지, 볼륨, 네트워크 등 모든 도커 리소스를 일괄 삭제
$ docker container stats [options]
- 시스템 리소스 사용 현황을 컨테이너 단위로 실시간 출력

2. Dockerfile 인스트럭션

FROM
- 빌드하는 이미지의 기반 이미지를 지정
RUN
- 이미지를 빌드할 때 컨테이너에서 실행할 명령어를 정의
COPY
- 호스트에서 컨테이너로 파일 및 디렉토리를 복사
ADD
- COPY의 기능에 압축 파일 자동 해제 및 URL로부터 컨테이너에 파일 및 디렉토리 추가
- 운영 체제를 담은 기반 이미지를 만들 때처럼 특수한 경우에 활용
CMD
- 컨테이너에서 포어그라운드로 실행할 명령어 정의
ENTRYPOINT
- 컨테이너를 실행 가능 파일로 사용할 때 정의하는 명령
- CMD와 ENTRYPOINT를 함께 사용할 수 있음
ARG
- docker image build를 실행할 때 사용하는 변수
ENV
- 컨테이너 안의 환경 변수를 정의
EXPOSE
- 컨테이너가 노출하는 포트
VOLUME
- 호스트나 다른 컨테이너에서 마운트할 수 있는 포인트 생성
LABEL
- 이미지에 추가하는 메타 데이터
STOPSIGNAL
- 컨테이너에 전달되면 컨테이너를 종료하는 시스템 시그널 설정
HEALTHCHECK
- 컨테이너 안에서 명령을 실행하고 그 결과를 헬스 체크에 사용
USER
- 컨테이너 실행 시 컨테이너 사용자. 이미지 빌드 시 USER 정의 뒤에 나오는 RUN 인스트럭셔도 해당 사용자 권한으로 실행
WORKDIR
- 컨테이너의 작업 디렉토리
ONBUILD
- 컨테이너 안에서 실행되는 명령을 정의
- 이미지에서는 실행되지 않음
- ONBUILD를 정의한 이미지를 기반 이미지로 삼아 다른 이미지를 빌드할 때 실행

3. 도커 컴포즈 명령어

$ docker-compose build [options]
- 컴포즈로 관리하는 서비스를 이미지로부터 빌드
$ docker-compose create [options]
- 컴포즈로 관리하는 서비스를 생성
$ docker-compose start [options]
- 컴포즈로 관리하는 서비스를 시작
$ docker-compose up [options]
- 컴포즈로 관리하는 서비스를 생성 및 시작
$ docker-compose stop [options]
- 컴포즈로 실행 중인 서비스를 정지
$ docker-compose rm [options]
- 컴포즈로 실행 중인 서비스를 삭제
$ docker-compose down [options]
- 컴포즈로 실행 중인 서비스를 정지 및 삭제
$ docker-compose ps [options]
- 컴포즈로 실행 중인 컨테이너의 목록을 출력
$ docker-compose logs [options]
- 컴포즈로 실행 중인 컨테이너의 로그를 요약해 출력

4. 도커 스웜/스택 명령어

$ docker swarm init [options]
- 스웜 클러스터를 초기화
$ docker swarm join [options] manager 호스트:포트
- 스웜 클러스터에 노드 혹은 매니저를 추가
$ docker swarm leave [options]
- 스웜 클러스터에서 노드 혹은 매니저를 제거
$ docker stack deploy [options] 스택명
- 스웜 클러스터에 스택을 배포
$ docker stack (ls | list) [options]
- 스웜 클러스터에 배포된 스택 목록을 출력
$ docker stack ps [options] 스택명
- 스택 안에서 실행 중인 태스크를 출력
$ docker stack (rm | remove | down) [options] 스택명
- 스웜 클러스터에서 스택을 제거
$ docker stack services [options] 스택명
- 스택에 포함된 서비스 목록을 출력

5. 헬름 명령어

$ helm init [options]
- 헬름을 초기화해 대상 쿠버네티스 클러스터를 배포할 수 있는 상태로 만든다.
- 옵션
  - --service-account : 틸러가 사용할 서비스 계정
  - --node-selector : 틸러를 배포할 노드의 레이블
  - --upgrade : 틸러 업그레이드
  - --history-max : 리소스 하나당 유지할 히스토리 최대 수
$ helm version
- 헬름 명령행 도구와 틸러의 버전을 확인한다.
$ helm create 차트명
- 헬름 차트의 템플릿을 생성한다.
$ helm lint 차트명
- 생성된 차트 템플릿이나 Chart.yaml, values.yaml 파일이 문법에 어긋나지 않는지 검사한다.
$ helm package [options] 차트_경로
- 차트를 압축 파일로 패키징한다.
- 옵션
  - --version : 차트의 버전
  - -d, --destination : 압축 파일을 출력할 디렉토리
$ helm repo list
- 헬름 명령행 도구로 사용할 수 있는 차트 리포지토리 목록을 출력한다.
$ helm repo add 리포지토리명 리포지토리URL
- 차트 리포지토리를 추가한다.
$ helm repo remove 리포지토리명
- 현재 등록된 차트 리포지토리를 삭제한다.
$ helm repo update
- 등록된 차트 리포지토리에서 최신 차트 정보를 받아온다.
- 반아온 정보는 로컬에 캐시되어 helm search 명령 등에 사용된다.
$ helm search [검색키워드] [options]
- 등록된 차트 리포지토리에서 원하는 차트 정보를 검색한다.
- 옵션
  - -r, --regexp : 키워드에 정규 표현식을 사용
  - -l, --version : 리포지토리에 등록된 버전 목록을 출력
$ helm fetch [options] 차트URL | 차트 리포지토리나 차트명
- 차트 리포지토리에서 패키지를 내려받는다.
- 옵션
  - --version : 내려받을 차트의 버전
- 사용 예시
  - $ helm fetch stable/redis
  - $ helm fetch stable/redis --version 3.6.0
$ helm serve [options]
- 로컬 리포지토리로 사용할 웹 서버를 시작한다.
- 옵션
  - --address : 서버가 개방할 주소(기본값은 127.0.0.1)
  - --repo-path : 차트 리포지토리가 될 로컬 디렉터리 경로
$ helm install 차트리포지토리/차트명 [optinos]
- 차트를 이용해 어플리케이션을 설치한다.
- 옵션
  - --dry-run : 설치 시뮬레이션을 수행한다.
  - --name : 릴리즈명(미지정 시 자동 생성)
  - -f, --value : YAML 파일의 경로 또는 URL(여러 개 지정 가능)
  - --version : 차트의 버전 지정
$ helm upgrade 릴리즈명 차트리포지토리명/차트명 [options]
- 기존에 설치된 릴리즈를 업데이트한다.
- 옵션
  - -f, --values : YAML 파일의 경로 혹은 URL(여러 개 지정 가능)
  - --version : 차트의 버전
  - --install : 릴리즈가 존재하지 않을 경우 새로 설치를 진행
  - --reuse-values : 마지막 릴리즈의 값을 재사용하고 새로운 값을 merge
$ helm list
- 설치된 릴리즈의 목록을 확인한다.
- 옵션
  - --deleted : 삭제된 릴리즈를 목록에 포함
  - --namespace : 지정한 네임스페이스의 릴리즈만을 확인
$ helm get [options] 릴리즈명
- 설치된 릴리즈의 상세 정보를 YAML 포맷으로 출력한다.
- 옵션
  - --version : 릴리즈의 버전
$ helm delete [options] 릴리즈명
- 설치된 릴리즈를 삭제한다.
- 옵션
  - purge : 릴리즈를 삭제하고 릴리즈명을 해제한다.

[2019] 오픈채팅방

Sun, 24 Nov 2019 18:14:39 +0900

문제 출처

문제 설명
- 오픈채팅방에선 친구가 아닌 사람들과 대화가 가능하다.
- 채칭방에 들어오거나 나갈 때 메시지가 출력된다.
- 닉네임을 변경하는 방법은 2가지가 있다.
  1. 채팅방을 나간 후, 새로운 닉네임으로 다시 들어온다.
  2. 채팅방에서 닉네임을 변경한다.
- 닉네임을 변경할 때는 기존에 채팅방에 출력되어 있던 메시지의 닉네임도 전부 변경된다.
- 채팅방은 중복 닉네임을 허용한다.
- 사용자는 유저아이디로 구분된다.
문제 풀이

[2019] 길 찾기 게임

Sun, 24 Nov 2019 18:15:16 +0900

문제 출처

문제 설명
1. 트리를 구성하는 모든 노드의 x, y 좌표 값은 정수이다.
2. 모든 노드는 서로 다른 x값을 가진다.
3. 같은 레벨에 있는 노드는 같은 y 좌표를 가진다.
4. 자식 노드의 y값은 항상 부모 노드보다 작다.
5. 임의의 노드 V의 왼쪽 서브 트리에 있는 모든 노드의 x값은 V의 x값보다 작다.
6. 임의의 노드 V의 오른쪽 서브 트리에 있는 모든 노드의 x값은 V의 x값보다 크다.
7. 노드들로 구성된 이진트리를 전위 준회, 후위 순회한 결과를 리턴한다.

[2020] 블록 이동하기

Wed, 27 Nov 2019 11:22:43 +0900

문제 출처

문제 설명
- 아래의 왼쪽과 같이 board의 정보가 input으로 주어진다.
- 0과 1로 이루어진 N x N 크기의 지도에서 2 x 1 크기의 로봇을 (1, 1) 에서 (N, N) 까지 이동시킨다.
- 시작은 아래의 왼쪽과 같이 시작한다.
- 로봇은 앞뒤 구분없이 움직일 수 있다.
- 로봇의 회전은 아래의 오른쪽과 같이 실행 할 수 있다.
- 로봇이 한칸 이동할 때 걸리는 시간은 1초이다.
- 90도 회전할 때 1초가 소요된다.

[2020] 외벽 점검

Wed, 27 Nov 2019 11:22:33 +0900

문제 출처

문제 설명
- 외벽이 원형으로 이루어진 레스토랑의 외벽을 점검한다.
- 외벽의 총 둘레는 n미터이다.
- 최소한의 인원을 투입하여 취약 지점을 점검한다.
- 정북 방향 지점을 0으로 한다.
- 인원들 각각이 1시간 동안 이동할 수 있는 거리는 다르다.
- 최대로 투입 가능한 인원의 수는 8명이 한계이다.
- 취약점의 최대 갯수는 15곳이다.
- 모든 인원을 투입해도 취약점을 전부 점검할 수 없을 경우 -1을 리턴한다.
예시

[2020] 괄호 변환

Wed, 27 Nov 2019 11:21:17 +0900

문제 출처

문제 설명
- 균형잡힌 괄호 문자열 : ‘(‘의 개수와 ‘)‘의 개수가 같다.
- 올바른 문자열 : ‘(‘와 ‘)‘의 괄호의 개수가 같고, 짝도 맞다.
- 해당 문제에서 제시된 설명은 다음과 같다.

입력이 빈 문자열인 경우, 빈 문자열을 반환합니다.
문자열 w를 두 “균형잡힌 괄호 문자열” u, v로 분리합니다. 단, u는 “균형잡힌 괄호 문자열"로 더 이상 분리할 수 없어야 하며, v는 빈 문자열이 될 수 있습니다.
문자열 u가 “올바른 괄호 문자열” 이라면 문자열 v에 대해 1단계부터 다시 수행합니다.
1. 수행한 결과 문자열을 u에 이어 붙인 후 반환합니다.
문자열 u가 “올바른 괄호 문자열"이 아니라면 아래 과정을 수행합니다.
1. 빈 문자열에 첫 번째 문자로 ‘(‘를 붙입니다.
2. 문자열 v에 대해 1단계부터 재귀적으로 수행한 결과 문자열을 이어 붙입니다.
3. ‘)‘를 다시 붙입니다.
4. u의 첫 번째와 마지막 문자를 제거하고, 나머지 문자열의 괄호 방향을 뒤집어서 뒤에 붙입니다.
5. 생성된 문자열을 반환합니다.

문제 풀이 : 문제에 제시되어 있는 설명을 참고하여 순차적으로 적용하면 된다.

#include <string>
#include <vector>

using namespace std;

//올바른 괄호인지 판별
bool is_right(string s)
{
	int cnt = 0;
	for (int i = 0; i < s.length(); i++)
	{
		if (s[i] == '(')
		{
			cnt++;
		}
		else if (s[i] == ')')
		{
			cnt--;
		}

		if (cnt < 0)
			return false;
	}

	if (cnt == 0)
		return true;

	return false;
}

//균형잡힌 문자열인지 판별
bool is_balanced(string s)
{
	int cnt = 0;
	for (int i = 0; i < s.length(); i++)
	{
		if (s[i] == '(')
		{
			cnt++;
		}
		else if (s[i] == ')')
		{
			cnt--;
		}
	}

	if (cnt == 0)
		return true;

	return false;
}

string solve(string s)
{
	if (s.length() == 0)
	{
		return "";
	}

	//문자열 s를 균형잡힌 문자열 u, v로 나눈다.
	string u = "", v;
	string ret = "";
	for (int i = 0; i < s.length(); i += 2)
	{
		v = s;
		u += s[i];
		u += s[i + 1];
		if (is_balanced(u))
		{
			v.erase(0, i + 2);
			if (is_balanced(v))
			{
				break;
			}
		}
	}

	//u, v가 모두 균형잡힌 상태에서
	//u가 올바른 문자열이라면
	if (is_right(u))
	{
		//ret에 u를 푸시하고 v를 검사한다.
		ret += u;
		ret += solve(v);
	}
	//u가 올바른 문자열이 아니라면
	else
	{
		//문제에 제시된 내용으로 해결한다
		ret += '(';
		ret += solve(v);
		ret += ')';

		int tmp = u.length();
		for (int i = 1; i < tmp - 1; i++)
		{
			if (u[i] == ')')
			{
				ret += '(';
			}
			else
			{
				ret += ')';
			}
		}
	}

	return ret;
}

string solution(string p)
{
	//올바른 괄호라면 원형 문자열을 리턴
	if (is_right(p))
	{
		return p;
	}

	//아니라면 괄호 변환을 실시하여 리턴한다.
	string ret = solve(p);

	return ret;
}

[2020] 자물쇠와 열쇠

Wed, 27 Nov 2019 11:21:28 +0900

카카오 블라인드 테스트 2020 - 자물쇠와 열쇠

문제 출처

문제 설명
1. 자물쇠의 크기 : M * M
2. 열쇠의 크기 : N * N
3. 열쇠는 회전과 이동이 가능하며 열쇠의 돌기 부분을 자물쇠 홈 부분에 맞게 채우면 자물쇠가 열리는 구조이다.
4. 열쇠를 자물쇠에 끼워 넣었을 때 빈 부분이 없어야 자물쇠를 열 수 있다.

[2020] 가사 검색

Wed, 27 Nov 2019 11:21:48 +0900

문제 출처

문제 설명
- 노래 가사에 사용된 단어들 중에 특정 키워드가 몇 개 포함되어 있는지 알 수 있는 프로그램

[2020] 기둥과 보 설치

Wed, 27 Nov 2019 11:22:18 +0900

문제 출처

문제 설명
- 기둥과 보 조건
  1. 기둥 : 바닥 위에 있거나 보의 한쪽 끝 부분 위에 있거나, 또는 다른 기둥 위에 있어야 한다.
  2. 보 : 한쪽 끝 부분이 기둥 위에 있거나, 또는 양쪽 끝 부분이 다른 보와 동시에 연결되어 있어야 한다.
- 위의 조건을 기준으로 설치/제거를 실시한다.
- 입력 : [ x, y , a, b ]
  1. x, y : 설치/제거하는 물체의 좌표
  2. a : 설치/제거할 구조물의 종류를 나타낸다. 0은 기둥, 1은 보
  3. b : 설치/제거를 알려준다. 0은 삭제, 1은 설치
- 기둥 : (x, y) 좌표 위쪽으로 설치 또는 제거
- 보 : (x, y) 좌표 오른쪽으로 설치 또는 제거
문제 풀이

[2020] 문자열 압축

Wed, 27 Nov 2019 11:21:08 +0900

문제 출처

문제 설명
- 데이터 처리 전문가가 되고 싶은 어피치는 문자열을 압축하는 방법에 대해 공부를 하고 있습니다. 최근에 대량의 데이터 처리를 위한 간단한 비손실 압축 방법에 대해 공부를 하고 있는데, 문자열에서 같은 값이 연속해서 나타나는 것을 그 문자의 개수와 반복되는 값으로 표현하여 더 짧은 문자열로 줄여서 표현하는 알고리즘을 공부하고 있습니다.