Learn Everywhere

 두 가지 모드가 있다 클래식 스웜 스웜 모드 차이점 클리식 스웜은 여러 대의 도커 서버를 관리하는 하나의 접근점을 제공 스웜 모드는 MSA 컨테이너를 다루기 위한 클러스터링 제공 클래식 스웜은 분산 코디네이터나 에이전트를 별도로 설치해야 함 스웜 모드는 컨테이너에서 기본적으로 제공 대부분 도커 서버를 클러스터링 해서 사용하기 때문에 스웜 모드로 많이 사용. cf) 분산 코디네이터(Distributed Coordinator) = etcd, zookepper, consul 등 스웜 모드 확인 $> docker info | grep Swarm Swarm: inactive 스웜 모드 클러스터 구축 아래 서버 3개라고 가정 swarm-manager : 10.10.10.111 swarm-worker1 : 10.10.10.201 swarm-worker2 : 10.10.10.202 1번 매니저에서 클러스터 시작 $> sudo docker swarm init --advertise-addr 10.10.10.111 --advertise-addr : 다른 도커에서 접근할 매니저 노드의 IP 출력에 클러스터 등록에 사용할 token이 나온다. ... docker swarm join --token ~~~~ 10.10.10.111 ... 2번 워커 노드에서 클러스터 등록 $> sudo docker swarm join --token {위에 토큰} 10.10.10.111 3번 워커 노드에서 클러스터 등록 $> sudo docker swarm join --token {위에 토큰} 10.10.10.111 1번 매니저에서 등록 노드 확인 $> docker node ls 1번 매니저에서 토큰 확인법 매니저 등록 토큰 $> docker swarm join-token manager $> docker swarm join-token --rotate manager -> 토큰 변경이 필요할때 워커 등록 토큰 $> docker swarm join-token w

도커 데몬 디버그 모드 $> dockerd -D 수행 명령어 보기 $> docker events $> docker system events ex) 이미지 관련 실행 명령어 보기 $> docker events --filter 'type=image' 자원 사용량 스트림으로 보기 $> docker stats 한번만 출력(no stream) $> docker stats --no-stream 이미지, 컨테이너, 로컬 볼륨 정보 $> docker system df 위 출력에서 사용중이지 않은 이미지 삭제(dangling image 삭제 -> <none>:<none>으로 표시된것) $> docker image prune 사용하지 않는 컨테이너 삭제 $> docker container prune 사용하지 않는 볼륨 삭제 $> docker volume prune CAdvisor https://github.com/google/cadvisor https://hub.docker.com/r/google/cadvisor/ 구글에서 만든 도커 모니터링 도구 그러나 단일 호스트에 대해서만 모니터링이 가능하기 때문에 PaaS로 도커 클러스터를 구축한다면 사용할 수 없음. 그래서 보통은 쿠버네티스나 도커 스웜과 같은 오케스트레이션 툴을 사용하고 Prometheus, InfluxDB 등을 이용해서 데이터를 수집한다.

도커 구성 도커 클라이언트 : 도커 cli 도커 데몬 : 실제 도커 프로세스  개발자 --> { (도커 클라이언트) -- /var/run/docker.sock --> (도커 데몬) }                                                                                                           ^                          (원격호스트) ------- curl {ip}:{port}/version ------| # ps aux | grep docker   로 도커 데몬(dockerd) 확인 가능 cf) 우분투는 도커 설치시 도커 데몬이 기본 실행된다. 레드헷 계열을 실행 시켜 줘야 한다. # sudo service docker start 로 실행 가능 # sudo dockerd -H unix://var/run/docker.sock  로 실행 가능 - 데몬은 옵션을 수동 실행시 줄 수도 있지만 /etc/default/docker(우분투)에 설정 파일로 지정 가능  # sudo service docker stop 로 실행 중단 # sudo systemctl enable docker 로  SystemV init 등록 도커 Remote API 도커 데몬 수동 실행 $> sudo service stop docker $> dockerd -H tcp://{dockerd 실행 호스트 IP}:2375  [-H unix://var/run/docker.sock] docker.sock은 도커 클라이언트가 사용하는 소켓. 따라서 없으면 remote api만 사용할 수 있고 docker 명령어 사용 불가. 확인 $> curl {dockerd 실행중인 IP}:2375/version --silent TLS 적용법 도커 데몬은 remote 접속시 기본적으로 보안이 적용되어 있지 않다. 1) 데몬 실행 $> sudo dockerd --tlsverify \      

X.509 Certificate Chainging 인증서 생성 Root CA는 자신의개인키로 self signing 한 인증서를 가지고 있음.(위 그림에선 생략) CA#1은 자신의 공개키를 Root CA에게 signing 요청(CSR)을 한다. Root CA는 자신의 개인키로 CA#1의 공개키를 sign 해 준다. sign 되면 이것이 CA#1의 인증서. 같은 방법으로 CA#2는 CA#1에게 자신의 공개키를 signing 요청(CSR) 한다. CA#1은 자신의 개인키로 CA#2의 공개키를 sign 해 준다. sign 되면 이것이 CA#2의 인증서. 반복~~ 인증 방법 그림처럼 인증서는 public key와 위 "인증서 생성" 과정을 거쳐 만든 전자 서명이 들어 있다. CA#1의 인증서를 확인하기 위해서는 Root CA의 public key로 CA#2의 인증서를 확인하기 위해서는 CA#1의 publick key로 ...반복 이런 식으로 인증서가 물려 있는 형태라 certificate chaining이라 부른다.

Dockerfile 작성 한줄에 하나의 명령어 명령어 뒤 옵션 명령어는 위에서 아래로 한 줄씩 차례대로 실행 명령어 대소문자 구분 없음 빌드 context는 Dockerfile이 위치한 디렉터리 ex) FROM ubuntu:14.04 MAINTAINER john123 LABEL "purpose"="practice" RUN apt-get update RUN apt-get install apache2 -y ADD test.html /var/www/html WORKDIR /var/www/html RUN ["/bin/bash", "-c", "echo hello >> test2.html"] EXPOSE 80 CMD apachectl -DFOREGROUND FROM 베이스 이미지(docker run에 사용하는 이름) MAINTAINER 이미지를 생성한 개발자 정보(1.13.0 이전 버전에서만. 이후는 LABEL로) = LABEL maintainer "alicek106 <alicek105@naver.com>" LABEL 이미지 메타데이터. 키:값 형태. docker inspect로 조회 가능 RUN 컨테이너 내부에서 명령어 실행. = RUN ["실행 가능한 파일", "명령줄 인자 1", "명령줄 인자 2", ...] ADD 파일을 이미지에 추가. 추가할 파일은 Dockerfile과 같은 디렉터리(context)에서 가져옴. = ADD ["추가할 파일 1", "추가할 파일 2", ... "컨테이너에 추가할 위치"] WORKDIR cd와 같음. EXPOSE 컨테이너의 포트 설정. 반드시 호스트 포트와 바인딩 되는 것은 아님. CMD 컨테이너 시작시 실행할 명령어. Dockerfile에 한번만 사용 가능. run으로 컨테이너 실행할 때 명령어를

 프로세스를 죽이는 방법은 SIGTERM과 SIGKILL 두 가지가 있다. 사용법) SIGTERM $> kill [-15] {process_id} -15가 default 임으로 안써도 된다. SIGKILL $> kill -9 {process_id} 차이점 SIGTERM은 process에게 중단 요청(graceful)을 한다. 즉, process는 이를 무시할 수도 있고 받아 들일 수도 있다. 그러나 SIGKILL은 받는 즉시 process가 죽는다. 그래서 SIGKILL로 죽이면 child가 parent에게(vice versa) 프로세스 종료를 알릴 겨를도 없기 때문에 좀비 프로세스를 만들 우려가 있다. 그러니 특별한 경우가 아니면 SIGTERM을 사용하도록.

Docker Image 생성 삭제  1. 이미지 생성 $> docker run -it --name commit_test ubuntu:14.04 컨테이너 내 파일 추가 root@abcd1234 /# echo test_first! >> first 2. 이미지 commit # docker commit [옵션] {컨테이너명} [리파지토리[:태그]] $> docker commit -a "abcd123" -m "first commit" commit_test commit_test:first -a : author -m : message 3. 이미지 확인 $> docker images 레이어 구조 확인 $> docker history {라파지토리[:태그]} 4. 이미지 삭제 $> docker rmi {리파지토리[:태그]} 5. 이미지 추출 & 원복 $> docker save -o ubuntu_14.04.tar ubuntu:14.04 $> docker load -i ubuntu_14.04.tar 6. FileSystem 추출 & 원복 $> docker export -o rootFS.tar mycontainer $> docker import rootFS.tar myimage:0.0 Docker Hub (https://hub.docker.com) 1. 이미지 검색 $> docker search {검색어} cf) 도커 이미지의 architecture 확인 $> docker inspect ubuntu | grep "Architecture" 2. 이미지 업로드 1) 도커 허브에 로그인 $> docker login 2) 이미지명에 repository 접두어 추가 $> docker tag my-image:0.0 alicek107/my-image:0.0 cf) 이미지 이름 변경법 # docker tag {기존 이미지명} {새로운 이미지명} 3)

 aws cli를 사용하기 위한 초기 설정(Mac 사용자) 1. aws cli download $> brew install awscli 2. aws session manager plugin 설치(SSM 필요한 사람만) $> brew tab dkanejs/aws-session-manager-plugin $> brew install aws-session-manager-plugin 3. aws key 설정 $> aws configure AWS Access Key ID [None] : {액세스 키 받은거 입력} AWS Secret Access Key [None] : {시트릿 키 받은거 입력} Default region name [None] : ap-northeast-2    <-서울 Default output format [None] : json 4. 확인 $> aws configure list

도커 이미지 컨테이너 생성 및 실행 $> docker run -i -t {이미지명} [시작 스크립트] -i : iteractive -t : tty 종료: 컨테이너 정지 $> exit 또는 ctrl + D 종료: 컨테이너는 계속 실행 ctrl + p, q run은 아래를 합친것 1) 이미지 다운로드 $> docker pull {이미지명} 2) 컨테이너 생성 $> docker create -i -t --name {컨테이너명} {이미지명} --name : 컨테이너 이름 설정 3) 컨테이너 실행 $> docker start {컨테이너명 | ID} 4) 컨테이너 접속 $> docker attach {컨테이너명 | ID} run vs create docker run: pull -> create -> start -> attach docker create: pull -> create 도커 이미지 다운로드 $> docker pull {이미지명} 도커 이미지 목록 확인 $> docker images 컨테이너 생성 / 삭제 목록 확인 $> docker ps $> docker ps --format "table {{.ID}}\t{{.Status}}\t{{.Image}}\t{{.Names}}" --format : formatting \t : tab $> docker ps -a -a : 정지된 컨테이너까지 모두 상태: Up(실행중) / Exited(종료) 컨테이너 정보 확인 $> docker inspect {컨테이너명} ex) container id 확인: docker inspect mysql | grep "Id" 컨테이너 이름 변경 $> docker rename {현재명} {바꿀명} 컨테이너 정지 $> docker stop {컨테이너명 | ID} 컨테이너 삭제 $> docker rm {컨테이너명 | ID} $> docker rm -f {컨테이너

EC2에 public 접속을 하기 위해 Elastic IP를 할당 했는데 Public DNS가 할당이 안될때 해결법. 원인: VPC의 DNS hostnames 기능이 disabled로 되어 있어 그렇다. 해결: enabled로 바꿔 주면 된다. 1. Services 메뉴에서 VPC 선택 2. 왼쪽에서 Your VOCs 선택 3. 우측 VPC 목록에서 사용중인 VPC 선택.(or 체크후 상단 Actions 클릭) 4. 팝업 메뉴에서 Edit DNS Hostnames 선택 후 enabled로 변경 cf) 위 이후 적용이 잘 안될땐 instance restart 해보시길~

  System Log Folder : /var/log System Log : /var/log/system.log Mac Analytics Data : /var/log/DiagnosticMessages System Application Logs : /Library/Logs System Reports : /Library/Logs/DiagnosticReports User Application Logs : ~/Library/Logs User Reports : ~/Library/Logs/DiagnosticReports

AWS에 네트워크 셋팅을 하다보면 종종 10.10.1.32/24와 같은 형태의 설정을 보게 된다. 이는 CIDR(싸이더) 표기법이며 위키에 아래와 같이 정의 되어 있다. *  위키백과 사이더 (Classless Inter-Domain Routing, CIDR)는 클래스 없는 도메인 간 라우팅 기법으로  1993년  도입되기 시작한, 최신의  IP  주소 할당 방법이다. 사이더는 기존의 IP 주소 할당 방식이었던  네트워크 클래스 를 대체하였다. 사이더는 IP 주소의 영역을 여러 네트워크 영역으로 나눌 때 기존방식에 비해 유연성을 더해준다. 특히 다음과 같은 장점이 있다. 급격히 부족해지는  IPv4  주소를 보다 효율적으로 사용하게 해준다. 접두어를 이용한 주소 지정 방식을 가지는 계층적 구조를 사용함으로써  인터넷  광역 라우팅의 부담을 줄여준다. 정의는 이렇고 실제 사용은 매우 간단하다.  10.10.1.32/24의 IP 주소가 있으면 /24는 IP 주소의 접두어(prefix)의 길이를 의미하고 이 길이 만큼 마스킹 된다. 10.10.1.32를 8bit로 표기해 보면 아래와 같고 00001010 . 00001010 . 00000001 . 00100000 |---------------- 24 bit ------------| /24는 위처럼 처음부터 24번째까지를 의미한다. 24번째까지 주소(10.10.1)를 접두어(고정)로 가진 2^8(8bit)개의 IP를 사용할 수 있다는 의미가 된다. 다른 예를 하나 들어 보면, 10.10.1.32/30 8bit로 표기하면 아래와 같다. 00001010 . 00001010 . 00000001 . 001000 00 |-------------------- 30 bit ------------------| 그러면 이 CIDR로 된 녀석들은 아래 4(2^2)개의 주소를 가질 수 있다는 의미가 된다. 10.10.1.32 -> 00001010 . 00001010 . 00000001 . 001000 00 10.10.1.33 -&g

JVM에 기본적으로 사용하면 좋을 옵션을 정리해 보았다. 더 자세한 내용을 보고 싶으면 출처에서 확인 바랍니다. 1) Max Heap Size Setting -Xmx2g unit g: giga byte m: mega byte k: kilo byte 2) Max Stack Size Setting -Xss256k 단위는 1번 참고 Default는 플랫폼마다 다름 값이 작으면 StackOverflowError 3) Max Metaspace Size Setting -XX:MaxMetaspaceSize=16m 단위는 1번 참고 기본값은 제한 없음. 4) G1 GC 사용하기 -XX:+UseG1GC java 8까지는 기본 설정값이 Parallel GC이고 java 9은 G1GC이다. 사용할 수 있는 GC 옵션(JDK11+)은 아래와 같다. GC Algorithm JVM argument Serial GC -XX:+UseSerialGC Parallel GC -XX:+UseParallelGC Concurrent Market & Sweep (CMS) GC -XX:+UseConcMarkSweepGC G1 GC -XX:+UseG1GC Shenandoah GC -XX:+UseShenandoahGC Z GC -XX:+UseZGC Epsilon GC -XX:+UseEpsilonGC 5) GC Logging -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:{file-path} JDK1 ~ JDK8까지 사용하던 방법 -Xlog:gc*:file={file-path} JDK 9+에서 사용할 수 있음 6) Heap Dump on OutOfMemory -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./heap-dump.hprop 7) Socket Connection & Read Timeout -Dsun.net.client.defaultConnectionTimeout=2000 -Dsun.net.clien

내용이 좋은 블로그가 있어 링크. 출처:  https://argolee.tistory.com/67

origin과 site의 정의가 한눈에 볼 수 있도록 매우 좋은 정의가 있어 가져 와봤다. - Origin - Site  출처의 내용이 좋으니 일독을 권합니다. 출처:  https://web.dev/same-site-same-origin/

@Fork의 warmup 어트리뷰트와 @Warmup 어노테이션의 차이를 StackOverflow에 정리가 잘된 답변이 있어 가져와 봤다. With a JMH benchmark you run one or more forks sequentially, and one or more iterations of your benchmark code within each fork. There are two forms of warmup associated with this: At the fork level the  warmups  parameter to  @Fork  specifies how many warmup forks to run before running the benchmarked forks. Warmup forks are ignored when creating the benchmark results. The  @Warmup  annotation lets you specify warmup characteristics within a fork, including how many warmup iterations to run. Warmup iterations are ignored when creating the benchmark results. For example: @Fork(value = 3, warmups = 2)  means that 5 forks will be run sequentially. The first two will be warmup runs which will be ignored, and the final 3 will be used for benchmarking. @Warmup(iterations = 5, time = 55, timeUnit = TimeUnit.MILLISECONDS)  means that there will be 5 warmup iterations within each fork. The timings from these runs will

tail recursion에 대한 좋은 블로그가 있어 가져와 봤다. 출처 :  https://homoefficio.github.io/2015/07/27/%EC%9E%AC%EA%B7%80-%EB%B0%98%EB%B3%B5-Tail-Recursion/ 재귀, 반복, Tail Recursion fibonacci(피보나치) 수열 잘 알려져 있듯 피보나치 수열은 다음과 같다. 1 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, ... 프로그래밍과는 관련 없는 얘기를 살짝 하자면, 이 수열의 이름은 본명은 Leonardo da Pisa이지만 fibonacci로 알려진 12세기 이탈리아 수학자의 이름을 따서 지어졌는데, 사실 이 수열을 가장 먼저 언급한 사람, 즉 가장 먼저 발견한 사람은 피보나치가 아니라  핑갈라 라고 하는 기원전 4세기 또는 2세기로 추정되는 시기의 인도인이라고 한다.  위키 참고 암튼 피보나치 수열은 다음과 같이 정의된다. 출처 :  위키피디아 위 식의 가장 아래줄을 보면 n번째 피보나치 수열의 숫자를 구하는 방법을 알 수 있다. 위 식을 그대로 JavaScript로 구현하면 다음과 같다. 참고로 앞으로의 구현 내용에는 n이 음수인 경우에 대한 예외처리는 편의상 생략한다. fibonacci 수를 구하는 가장 직관적인 구현 1 2 3 4 5 function fibonacci ( n ) { if (n < 2 ) return n; return fibonacci(n - 1 ) + fibonacci(n - 2 ); } 피보나치 수의 정의 자체가 재귀 호출 관계를 내포하고 있으므로, 구현 역시 재귀 호출을 포함하게 된다. 콘솔에서  fibonacci(0) ,  fibonacci(1) ,  fibonacci(2) ,  fibonacci(3) , … 을 여러 개 실행해보면 맞는 답이 나온다. 그럼 여기서 얘기 끝? 물론 아니다.  fibonacci(100) 을 실행하면 어떨까? 콘솔이 답을 금방 뱉어내질 않는다.