맥북에서 도커 네트워크(brider)를 생성하는 예시이다. 


$ docker network create --driver=bridge mynet

1e322c39b6415e3d6b76bee009e8282d6e9e738e9b35930abc875c1cf20578fa

$ docker network ls | grep mynet

1e322c39b641        mynet                           bridge              local


정상적으로 드라이버가 생겼는지 확인한다.


$ ifconfig

(리눅스에서는 ip addr | grep br-)


bridge0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500

options=63<RXCSUM,TXCSUM,TSO4,TSO6>

ether 4a:00:24:80:b7:01

Configuration:

id 0:0:0:0:0:0 priority 0 hellotime 0 fwddelay 0

maxage 0 holdcnt 0 proto stp maxaddr 100 timeout 1200

root id 0:0:0:0:0:0 priority 0 ifcost 0 port 0

ipfilter disabled flags 0x2

member: en1 flags=3<LEARNING,DISCOVER>

        ifmaxaddr 0 port 13 priority 0 path cost 0

member: en2 flags=3<LEARNING,DISCOVER>

        ifmaxaddr 0 port 14 priority 0 path cost 0

member: en3 flags=3<LEARNING,DISCOVER>

        ifmaxaddr 0 port 15 priority 0 path cost 0

member: en4 flags=3<LEARNING,DISCOVER>

        ifmaxaddr 0 port 16 priority 0 path cost 0

nd6 options=201<PERFORMNUD,DAD>

media: <unknown type>

status: inactive



생성된 네트워크(bridge)를 사용하는 컨테이너를 실행한다.


$ docker run -it -d --name container1 --net=mynet ubuntu:16.04 bash  



두 번 커맨드를 사용해 생성된 네트워크(bridge)를 사용할 수 있다.


$ docker run -it -d --name container2 ubuntu:16.04 bash           


$ docker network connect mynet container2




내부 ip를 확인해본다.


$  docker exec container1 ip addr

20: eth0@if21: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default

    link/ether 02:42:ac:19:00:02 brd ff:ff:ff:ff:ff:ff

    inet 172.25.0.2/16 brd 172.25.255.255 scope global eth0

       valid_lft forever preferred_lft forever

       

$  docker exec container2 ip addr 


(비슷하게 나온다)


Posted by 김용환 '김용환'

댓글을 달아 주세요

공용 IP 얻기

Web service 2019.09.14 16:28



PC에서 공용 Ip를 찾는 방법이다.


보통은 eth0을 찾기 위해 ifconfig 또는 ip address list를 실행하는데, 도커나 가상 네트워크 등을 설치/설정하면서 복잡해질 때가 있다.


브라우져에서 https://ifconfig.co 를 실행하거나 


curl https://ifconfig.co를 실행한다.

'Web service' 카테고리의 다른 글

공용 IP 얻기  (0) 2019.09.14
[sentry] nginx, PG 매개 변수 튜닝  (0) 2019.03.21
firefox 쿠키 파싱하기 - lz4json  (0) 2018.10.23
크롬 브라우저의 쿠기 확인하기 - sqlite  (0) 2018.10.20
[jquery] file upload 예제  (0) 2017.05.30
구글 place api : request_denied  (0) 2016.06.28
Posted by 김용환 '김용환'

댓글을 달아 주세요


플랫 네트워크(flat network) - 비용, 유지 관리, 관리를 줄이기 위한 컴퓨터 네트워크 설계 방식으로서 장치를 별도의 스위치 대신 단일 스위치에 연결하여 컴퓨터 네트워크의 라우터와 스위치 개수를 줄이는 방식이다. 즉 중간 단계 없이 직접 통신할 수 있는 방식을 말한다. 따라서 계층적 네트워크(hierarchy network)와 달리 플랫 네트워크는 스위치를 사용해 물리적으로 분리되지 않는다

플랫 네트워크의 예로 도커의 브릿지(bridge)를 예로 들 수 있다.

도커의 브릿지는 컨테이너 간의 플랫 네트워크(flat network)를 생성하고 요청을 외부에 외부 연결로 전달한다.

Posted by 김용환 '김용환'

댓글을 달아 주세요



kubernetes의 Service.spec.type의 기본값은 ClusterIP이다. 

clusterip는 iptables 기반이다.  k8s 서비스를 클러스터 내부 IP에 노출하고 클러스터 내에서만 서비스에 도달할 수 있게 한다. 


(참고 : kubernetes)





이외 3가지가 더 있다. 

Ingress를 사용하지 않으면 Nodeport를 사용한다. 

하지만 개인적으로 Ingress를 두는 것이 운영하는 데 훨씬 도움이 되는 것 같다. 


LoadBalancer는 LBaaS로 사용자가 로드 밸런서를 추가할 수 있는 형태이다.


아마존의 경우는 아래와 같이 사용할 수 있다. 

https://aws.amazon.com/ko/blogs/opensource/network-load-balancer-nginx-ingress-controller-eks/




https://github.com/kubernetes/ingress-nginx/blob/master/docs/deploy/index.md




실제 사용 예를 살펴본다. 아래 ingress-nginx에 잘 나와 있다. 

https://github.com/kubernetes/ingress-nginx/blob/master/docs/deploy/index.md


type이 LoadBalancer 타입일 경우에는 어떻게 설정되어 있는지 확인할 수 있다. 


aws L4 LB를 사용하려면 다음과 같이 사용한다. 

https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/static/provider/aws/service-l4.yaml

kind: Service
apiVersion: v1
metadata:
  name: ingress-nginx
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
  annotations:
    # Enable PROXY protocol
    service.beta.kubernetes.io/aws-load-balancer-proxy-protocol: "*"
    # Ensure the ELB idle timeout is less than nginx keep-alive timeout. By default,
    # NGINX keep-alive is set to 75s. If using WebSockets, the value will need to be
    # increased to '3600' to avoid any potential issues.
    service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout: "60"
spec:
  type: LoadBalancer
  selector:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
  ports:
    - name: http
      port: 80
      targetPort: http
    - name: https
      port: 443
      targetPort: https

---



l7인 경우는 다음과 같이 설정한다. 

https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/static/provider/aws/service-l7.yaml


kind: Service
apiVersion: v1
metadata:
  name: ingress-nginx
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
  annotations:
    # replace with the correct value of the generated certificate in the AWS console
    service.beta.kubernetes.io/aws-load-balancer-ssl-cert: "arn:aws:acm:us-west-2:XXXXXXXX:certificate/XXXXXX-XXXXXXX-XXXXXXX-XXXXXXXX"
    # the backend instances are HTTP
    service.beta.kubernetes.io/aws-load-balancer-backend-protocol: "http"
    # Map port 443
    service.beta.kubernetes.io/aws-load-balancer-ssl-ports: "https"
    # Ensure the ELB idle timeout is less than nginx keep-alive timeout. By default,
    # NGINX keep-alive is set to 75s. If using WebSockets, the value will need to be
    # increased to '3600' to avoid any potential issues.
    service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout: "60"
spec:
  type: LoadBalancer
  selector:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
  ports:
    - name: http
      port: 80
      targetPort: http
    - name: https
      port: 443
      targetPort: http

---






마지막으로 EnternalName은 CoreDNS에서 지원하는 CNAME 값이다. 







지금까지 설명한 내용은 다음 문서에 있다. 

https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types


  • ClusterIP: Exposes the Service on a cluster-internal IP. Choosing this value makes the Service only reachable from within the cluster. This is the default ServiceType.
  • NodePort: Exposes the Service on each Node’s IP at a static port (the NodePort). A ClusterIP Service, to which the NodePort Service routes, is automatically created. You’ll be able to contact the NodePort Service, from outside the cluster, by requesting <NodeIP>:<NodePort>.
  • LoadBalancer: Exposes the Service externally using a cloud provider’s load balancer. NodePort and ClusterIP Services, to which the external load balancer routes, are automatically created.
  • ExternalName: Maps the Service to the contents of the externalName field (e.g. foo.bar.example.com), by returning a CNAME record

    with its value. No proxying of any kind is set up.



Posted by 김용환 '김용환'

댓글을 달아 주세요



(이미지만 참고) Refernece : https://www.youtube.com/watch?v=TFAASAfO_gg





외부 또는 중요한 내부 서버와 통신할 때 ACL을 뚫어서 통신할 때가 있다.


현재 kubernetes 클러스터의 서버(node)만 보고 ACL을 뚫으면 나중에 새로운 서버가 추가되고 새로운 장비에 실행된 pod에서는 막힌 부분 때문에 에러가 발생할 것이다.



특정 장비(node)에만 pod를 배포하면 이슈가 없을 것이다.



이에 대한 2가지 방법이 있다.


1. pod 적용


이 방식은 공식 문서에 있는 방식이다. 



https://kubernetes.io/docs/concepts/configuration/assign-pod-node/






2. deployment 적용




$ kubectl label nodes google-k8s-worker001 server=google-config

$ kubectl label nodes google-k8s-worker002 server=google-config



$ kubectl get nodes -l server=google-config
NAME               STATUS   ROLES   AGE   VERSION
google-k8s-worker001   Ready    node    14d   v1.11.5

google-k8s-worker002   Ready    node    14d   v1.11.5
 


apiVersion: apps/v1beta2
kind: Deployment
metadata:
name: google-config
namespace: production
spec:
selector:
matchLabels:
app: google-config
replicas: 2
minReadySeconds: 5
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 3
maxUnavailable: 3
template:
metadata:
labels:
app: google-config
spec:
nodeSelector:
server: google-config

containers:
- name: google-config
image: dockerhub-url
imagePullPolicy: Always


테스트 방법은 다음과 같다. 

google-config를 1번 2번 장비에서만 실행되게 했다.


$ kubectl delete pod $(kubectl get pods | grep config | awk '{print $1}') 


삭제된 pod가 계속 1번 2번 장비에서 실행되는지 확인한다.




Posted by 김용환 '김용환'

댓글을 달아 주세요



도커 파일에서 env를 사용할 때 항상 env를 사용할 수 없다.

RUN, CMD, ENTRYPOINT에만 사용할 수 있다.


나 같은 경우는 k8s를 사용하고 런타임에 PHASE를 사용할 것이라 ENTRYPOINT에 추가했다.


ENV PHASE production
...
ENTRYPOINT /usr/src/app/docker-entrypoint.sh "$PHASE"


실제 docker-entrypoint.sh 를 다음과 같이 구성했다.


#!/bin/sh

ln -sf /etc/nginx/$1.nginx-vhost.conf /etc/nginx/nginx-vhost.conf

service nginx start

phantomjs --ssl-protocol=any rasterize.js



빌드는 다음과 같이 해서 테스트할 수 있다.


docker build -t voucher-renderer .

docker run -p 80:80 -e PHASE="sandbox" -it voucher-renderer


Posted by 김용환 '김용환'

댓글을 달아 주세요


docker run에 환경 변수를 전달할 때 


주의해야 할 사항이 있다.  순서이다.



동작 안하는 예시이다. -it 뒤에 -e을 사용하면 적용이 안된다.

docker run -p 80:80  -it -e PHASE="sandbox" voucher-renderer


-it 플래그와 -e 플래그를 분리해야 한다.

docker run -p 80:80 -e PHASE="sandbox" -it voucher-renderer


Posted by 김용환 '김용환'

댓글을 달아 주세요



 kubernetes 에서 tls 정보를  namespace별로 저장한다.




#!/usr/bin/env bash

root="$(cd "$( dirname "${BASH_SOURCE[0]}")/.." && pwd )"
source $root/.env
cd $root

kubectl config use-context google-production-context

declare -a phases=("sandbox" "beta" "production")
for phase in "${phases[@]}"
do
echo "$phase"
## google.com secret 생성하기
kubectl create secret tls google-com --key $root/cert/google.com.key --cert $root/cert/google.com.crt -n $phase

## kakao.com secret 확인하기
kubectl describe secret google-com -n $phase
done

## 인증서 확인하기
kubectl get cm -n ingress-nginx ingress-nginx -o yaml


인증서를 tls 정보로 변경할 때 유의할 점은 namespace 별로만 인증서를 인식한다.


즉 production namespace에서 default에 저장된 tls 인증서를 찾지 못한다. 

Posted by 김용환 '김용환'

댓글을 달아 주세요

kube-prompt

분류없음 2019.09.09 13:45



https://github.com/c-bata/kube-prompt 는 쿠버네티스 커맨드 자동 완성기이다.



macOS 설치 방법은 다음과 같다. 


 brew install c-bata/kube-prompt/kube-prompt



사용 방법은 간단하게 kube-prompt를 실행하고 kubectl 다음의 하위 커맨드를 사용한다.




Posted by 김용환 '김용환'

댓글을 달아 주세요


이번에 회사에서 동료들의 if kakao 2019 발표 프레젠테이션을 도운 내용(컨설팅?) 을 정리해 본다.


사실 나도 잘 못해서 늘 부끄럽다. 그래도 처음 발표하는 사람들 입장에서는 두렵고 떨리고 도움 받고 싶을 것 같아서. 기록차원에서 남겨둔다.




(예전에 발표했던 사진이다. 허접함이 넘친다. 배울 것이 많던 시절이다)





1. 업무하면서 발표준비하기 때문에 건강을 잘 챙기면서 간다.

발표일까지 마라톤이라 생각하고 1달 정도부터는 잘 진행한다.

발표 일주일 동안은 문서 생각은 뒤로 하고 즐겁게 다니고 건강을 잘 챙긴다. 많이 초조해지는 시기..



2. 스토리텔링 위주로 정리하는 것이 좋다. (기억이 잘 나게 한다)

의도를 명확히 하기 위해 그림을 잘 사용한다.



3. 논란이나 오해할 만한 내용은 자세하게 그리지 말고

말로 중요만 찍고 넘어 간다. 발표 프레젠테이션의 목표만 살펴본다.



4. 발표 자료의 오타, 자간, 필요없는 부제목, 연관없는 내용이 없게 한다.

글자 폰트는 너무 작게 하면 뒤에서 안 보인다.  한 장에 너무 많은 내용을 품으면 청중이 잘 이해를 못한다. 발표 자료를 한 장에 꽉 채우지 않게 하고 하단 20%는 버려야 한다. 뒤에 있는 청중이 잘 볼 수 있게 한다.

(이 부분이 발표자의 감정을 상하게할까봐 조심스러웠다. 질문과 답 형태로 정말 이 발표 프레젠테이션이 잘되면 좋겠다는 마음으로 진행한다)



5. 수치(성능) 자료가 있을 때는 명확한 내용이 나오게 한다. 

애매하다면 차라리 뺀다. 



6. 발표 프레젠테이션의 그림 자료는 중요하다.

캡쳐한 것은 의외로 화질이 안좋고, 기본 제공하는 이미지나 박스는 그렇게 예쁘지 않다.


구글에서 "free icon 단어"로 검색해서 저작권 없는 이미지가 있으니 일관성 있는 느낌이 되도록 그림을 추가한다.


ex) "free icon corn" 검색

"카카오톡 프레젠테이션" 검색



7. 발표 내용은 모두 외우는 것이 좋다. 그래서 스토리텔링 위주가 좋다는 게 그 배경이다.

(예전에 삼성전자에서 발표하다가 프레젠테이션이 문제가 있어서 컴퓨터가 아예  작동이 안된 적이 있었다. 그때 도움이 되었다)



8. 발표가 끝날 때까지 끝난게 아니다.  실수하면 당황할 수 있는데..  만회하면 된다. 편하게 즐겁게 한다.



9. 발표 끝나면 짧으면 몇 시간, 길면 한 달동안  여러 감정(공허감, 인정, 자존감, 인정받고 싶은 감정)이 왔다 갔다 한다.. 나는 나름 훈련할 때. 이런 생각을  했다 "나는 특별한 사람이 아니다. 그냥 발표 한 번 한 것이다." 이렇게 생각하고 현업에 잘 집중하려고 노력한다. 




이외..


진지한게 좋을까? 농담하는 것이 좋을까?(분위기 업)





진지/농담에 대한 부분은 정답은 없는데..  


경험한 내용으로 봤을때


어설픈 농담보다는 그냥 진지한게 100~1000배 낫다. 청중의 관심을 끄는 데 도움이 되겠지만 주제에 부합되는 부분이 아닌 농담은 안하는 게 낫다. (발표 내용이 아니라 자신을 더욱 돋보이려는 의도가 있을 때.. 언젠가 안 좋은 쪽으로 돌아왔다)




유머는 발표 목적에 부합될 때 사용하는 것이 좋다. 본인의 경험한 얘기를 얘기하고 어떻게 이겨냈는지 자신의 얘기를 하면서 즐겁게 얘기하는 수준도 좋다. 수백번 말로 설득하는 것보다 경험한 하나의 얘기가 청중을 사로 잡는다. 



긴장감없고 자연스러울 때 유머가 자연스럽게 나온다 .



안좋은 상황 또는 진지한 상황에서 유머하면 먹히지 않는다. 더 싸해진다. 그 때는 발표 목적에만 집중한다. 진지한 분위기를 억지로 띄울 필요가 없다. 



공격할 목적으로 유머는 하지 않아야 한다(반성 중..) 






그 다음에는 그림 자료를 보여줄 때 잠깐 기다려주는(멈추는) 것이 좋을까?  아니면 바로 그림 설명을 할까? 에 대한 내용이다.


침묵은 청중을 한 번에 집중하는 효과를 갖는다. 중요한 내용, 정말 하고 싶었던 내용, 중요한 그림, 고민이 필요한 내용에 잠깐 2-3초 쉬어주면 청중 모두가 발표자를 쳐다본다.


그 때 하고 싶은 말을 진행한다. 그러나 너무 오래 남발해서 의미 없는 발표 자료까지 집중시키려 하면 더 이상 쳐다보지 않는다. 경험상 2-3번 정도가 좋은 것 같다. 









Posted by 김용환 '김용환'

댓글을 달아 주세요

  1. Favicon of https://blog.voidmainvoid.net BlogIcon AndersonChoi 2019.09.09 10:37 신고  댓글주소  수정/삭제  댓글쓰기

    좋은 글 잘 읽고갑니다~! 감사합니다.