https://cncg-kr.net/ 에서 발표한 내용입니다.
IT 서비스를 구성하는데에는 다양한 자원들(Baremetal server, Virtual machine, network switch, database, 등)이 필요합니다. 이런 자원들은 각각의 관리자등을 통해서 일반적으로 각기 다른 방법들로 관리됩니다. 다만 IaaS, PaaS와 같은 Cloud방법들이 제공되면서 보다 통합된 환경으로 이런 자원들을 관리 하게 되었으나 아직까지도 일반적으로는 이런자원들을은 각기 관리되어 불편함과 문제가 수반 됩니다. 그래서 저희는 이런 다양한 자원과 방법들을 kubernetes로 보다 선언적이며 통합적인 방법으로 만들어서 자동화를 하였고 이 세션에서는 이 내용을 소개하며 어떻게 하면 이런방법들로 접근 할 수 있을지 설명하고 이를 통해 kubernetes 에 더 많은 가능성들에 대해 알아보고자 합니다.
데브시스터즈의 Cookie Run: OvenBreak 에 적용된 Kubernetes 기반 다중 개발 서버 환경 구축 시스템에 대한 발표입니다.
Container orchestration 기반 개발 환경 구축 시스템의 필요성과, 왜 Kubernetes를 선택했는지, Kubernetes의 개념과 유용한 기능들을 다룹니다. 아울러 구축한 시스템에 대한 데모와, 작업했던 항목들에 대해 리뷰합니다.
*NDC17 발표에서는 데모 동영상을 사용했으나, 슬라이드 캡쳐로 대신합니다.
이제 컨테이너는 IT 산업 전반에서 빼놓을 수 없는 구성요소로 자리 잡고 있습니다. 이런 컨테이너는 일반적으로 가상화 기술로 소개가 되어 virtual machine과 비교되고 있습니다. 하지만 이런 접근 방법들이 컨테이너를 올바르게 이해하도록 하는데 방해가 될 수도 있다고 생각합니다.
이 세션에서는 컨테이너에 대해서 여러가지 다양한 접근 방법들과 기능들을 살펴보면서 컨테이너에 대해 다시금 생각 해볼 수 있는 시간을 갖고자 합니다. 또한 이를 통해 어떤식으로 실제 production 환경들에서 사용되어질 수 있을지 그리고 이런 모습들로 부터 향후 컨테이너의 발전방향을 이야기 해보려고 합니다.
Docker 기본 및 Docker Swarm을 활용한 분산 서버 관리 A부터 Z까지 [전체모드에서 봐주세요]David Lee
저희 팀에서 Docker Swarm을 처음 도입한 계기는 사실 배포 자동화 프로세스 구축하고 싶었기 때문이었습니다.
처음엔 서버가 하나 뿐이여서 컨테이너 오케스트레이션의 묘미를 느끼지 못했는데 관리자, 푸시, 이벤트, 테스트 등등 여러 서버가 붙으면서 여러개의 서버를 관리해야 했는데
미리 구축해놓은 Docker Swarm이 많은 편의 기능을 제공하고 있어서 여러개의 서버를 관리하는 것도 개발자가 부담없이 할 수 있게 되었습니다.
이 슬라이드는 제가 서버를 구축하는 과정에서 겪었던 어려움들을 여러분은 겪지 않길 바라며 제작하게 되었습니다.
만약 이 슬라이드를 보시는 분이 Docker및 Docker Swarm을 처음 접해보시는 거라면 이 자료가 좋은 가이드가 될 수 있을 것 같습니다.
감사합니다.
이도현 드림
https://cncg-kr.net/ 에서 발표한 내용입니다.
IT 서비스를 구성하는데에는 다양한 자원들(Baremetal server, Virtual machine, network switch, database, 등)이 필요합니다. 이런 자원들은 각각의 관리자등을 통해서 일반적으로 각기 다른 방법들로 관리됩니다. 다만 IaaS, PaaS와 같은 Cloud방법들이 제공되면서 보다 통합된 환경으로 이런 자원들을 관리 하게 되었으나 아직까지도 일반적으로는 이런자원들을은 각기 관리되어 불편함과 문제가 수반 됩니다. 그래서 저희는 이런 다양한 자원과 방법들을 kubernetes로 보다 선언적이며 통합적인 방법으로 만들어서 자동화를 하였고 이 세션에서는 이 내용을 소개하며 어떻게 하면 이런방법들로 접근 할 수 있을지 설명하고 이를 통해 kubernetes 에 더 많은 가능성들에 대해 알아보고자 합니다.
데브시스터즈의 Cookie Run: OvenBreak 에 적용된 Kubernetes 기반 다중 개발 서버 환경 구축 시스템에 대한 발표입니다.
Container orchestration 기반 개발 환경 구축 시스템의 필요성과, 왜 Kubernetes를 선택했는지, Kubernetes의 개념과 유용한 기능들을 다룹니다. 아울러 구축한 시스템에 대한 데모와, 작업했던 항목들에 대해 리뷰합니다.
*NDC17 발표에서는 데모 동영상을 사용했으나, 슬라이드 캡쳐로 대신합니다.
이제 컨테이너는 IT 산업 전반에서 빼놓을 수 없는 구성요소로 자리 잡고 있습니다. 이런 컨테이너는 일반적으로 가상화 기술로 소개가 되어 virtual machine과 비교되고 있습니다. 하지만 이런 접근 방법들이 컨테이너를 올바르게 이해하도록 하는데 방해가 될 수도 있다고 생각합니다.
이 세션에서는 컨테이너에 대해서 여러가지 다양한 접근 방법들과 기능들을 살펴보면서 컨테이너에 대해 다시금 생각 해볼 수 있는 시간을 갖고자 합니다. 또한 이를 통해 어떤식으로 실제 production 환경들에서 사용되어질 수 있을지 그리고 이런 모습들로 부터 향후 컨테이너의 발전방향을 이야기 해보려고 합니다.
Docker 기본 및 Docker Swarm을 활용한 분산 서버 관리 A부터 Z까지 [전체모드에서 봐주세요]David Lee
저희 팀에서 Docker Swarm을 처음 도입한 계기는 사실 배포 자동화 프로세스 구축하고 싶었기 때문이었습니다.
처음엔 서버가 하나 뿐이여서 컨테이너 오케스트레이션의 묘미를 느끼지 못했는데 관리자, 푸시, 이벤트, 테스트 등등 여러 서버가 붙으면서 여러개의 서버를 관리해야 했는데
미리 구축해놓은 Docker Swarm이 많은 편의 기능을 제공하고 있어서 여러개의 서버를 관리하는 것도 개발자가 부담없이 할 수 있게 되었습니다.
이 슬라이드는 제가 서버를 구축하는 과정에서 겪었던 어려움들을 여러분은 겪지 않길 바라며 제작하게 되었습니다.
만약 이 슬라이드를 보시는 분이 Docker및 Docker Swarm을 처음 접해보시는 거라면 이 자료가 좋은 가이드가 될 수 있을 것 같습니다.
감사합니다.
이도현 드림
AWS는 다양한 서비스 빌딩 블록을 이용하여, 고객의 요구에 따른 다양한 사물 인터넷(IoT) 서비스를 구축할 수 있습니다. 본 온라인 세미나에서는 AWS IoT 서비스의 주요 개념과 함께 일반적인 인터넷 기기 및 스마트 홈을 위한 IoT 서비스 구현 패턴을 알아봅니다. 이를 위해 데이터 상태 관리, 데이터 분석 및 자원 관리 등의 패턴을 통해 비용 효율적이고 확장 가능한 아키텍처를 살펴봅니다.
AWS Lambda, API Gateway, DynamoDB 등 서버리스 빌딩 블록과 AWS IoT를 연계한 iRobot의 아카텍처 사례를 함께 살펴봄으로서 IoT 기반 서비스 구현 및 이전에 통찰력을 얻으실 수 있습니다.
Présentation d'un service innovant permettant de faciliter l'intégration de cadres de la maintenance en usine grâce à un parcours de formation appliquée et en fonction des besoins de l'usine.
An Overview of Analytics App made for Clover POS System.
Analytics App provides detailed and visual REPORTS, DASHBOARDS, COMMISSIONS and other business insights for managers and business owners. „If You Can't Monitor It, You Can't Manage It“
What do you like to do:
☻Safari tours
☻ Mounting climbing
☻Beach tours
☻Wildlife and birds watching
☻ Day Tour Trips
☻Transfer Services
☻Walking in Community
Heterosexualidad En Amenaza De Extincionguestdf513d8
ES LA PRESENTACION DE LA HETEROSEXUALIDAD COMO SE VE AMENAZADA POR EL AUMENTO DE LA POBLACION HOMOSEXSUAL EN EL MUNDO Y LA PROBLEMATICA DEL TERMINO "PREFERENCIA SEXSUAL:"
User Experience for Mobile (for Cambridge Mobile App Group)Roger Attrill
Considerations for the user experience when transitioning content from the desktop to the mobile platform, whether that's websites, apps, or websites that behave like apps.
What you might want to consider when it seems to be too late for the ‘Mobile First’ methodology.
Designing the user experience around the constraints and capabilities that mobile provides and the types of user behaviour that mobile entails.
The relationship between desktop and mobile content and the cross channel experience.
There's an in depth look at a couple of examples and the talk should be of interest to designers, developers, researchers (in fact, basically anyone) involved with, or just interested in, projects for mobile devices.
Note: this is a slightly updated version of a talk given at Mobile East conference in 2012: http://www.slideshare.net/Think-ui/mobile-ux-13487681
You can find the raw presentation notes for that talk at
http://www.thinkui.co.uk/resources/the-mobile-user-experience/
Vastgoedfirma prins Laurent teert op subsidiesThierry Debels
De vastgoedonderneming CERBUX INVEST boekt zware verliezen. Die verliezen zouden nog groter zijn zonder subsidies. In de laatste twee boekjaren werd telkens een deel van de subsidie in rekening gebracht.
The experts at Goldstone Financial Group detail what people approaching retirement age should know about repaying any student loan debt they might have.
[오픈소스컨설팅] Docker를 활용한 Gitlab CI/CD 구성 테스트Ji-Woong Choi
Docker를 활용하여 Gitlab CI/CD 설치 구성 및 샘플 테스트를 위한 가이드 문서이며, Docker 및 Gitlab에 대한 개요 및 사용법에 대해서는 다루지 않습니다. Docker image를 이용 Gitlab 및 Gitlab CI/CD 설치 및 구성 후 Sample Spring boot web application을 이용하여 소스 변경에 따른 commit이 발생 했을 때 Gitlab CI/CD 기능을 통해 application 테스트, 빌드, 배포까지의 일련의 과정이 자동으로 진행되는지를 테스트 하는 내용입니다.
[IoT] MAKE with Open H/W + Node.JS - 3rdPark Jonggun
IoT 시대에 Opensource H/W 와 NodeJS 를 이용하여 누구나 나만의 H/W + S/W + Service 를 만들기 위한 교육 과정을 만들어 보았습니다.
상상했던 아이디어를 Raspberry Pi 기반으로 나만의 IoT 제품을 현실로 만들어 보세요.
Lesson 1 - Introduction : IoT개요, Opensource H/W, 라즈베리파이 기초
Lesson 2 - Linux : Raspberry Pi 에서 리눅스 활용하기
Lesson 3 - Node.JS : Raspberry Pi 에서 Node.JS 로 프로그래밍 하기
Lesson 4 - Sensor : GPIO 를 Node.JS 로 동작시켜 센서 제어하기
Lesson 5 - Project : Raspberry Pi 로 스마트폰 + 무선 IoT 오디오 제작
챕터가 완성되는대로 추가적으로 공유하겠습니다.
Circulus Site - http://www.circul.us
Circulus Group - http://group.circul.us
Spark
Hadoop
HDFS
Spark Cluster
Docker
Google Cloud Platform
GCP
DataProc
Google Cloud Storage
Google Vision API
Google Translation API
Google Natural Language API
ARM과 AMD64의 차이에 대해 설명하고
오픈스택에 ARM을 도입하기 위한 커뮤니티 활동을 소개합니다.
1. ARM vs AMD64
2. CISC/RISC 차이
3. 커뮤니티에서 ARM위에 오픈스택을 올리기 위한 노력
- SIG (Special Interest Groups)
- PTG(Project Team Gathering)
1. Kubernetes on GCP
Daegeun Kim (gnkr8@outlook.com)
Lezhin Entertainment
1
1편으로 생각해주세요. 40분안에 하기에는 주제가 너무컸습니다.
2. 발표자
✑ 레진엔터테인먼트 데이터 엔지니어
✑ Links
✑ https://geekdani.wordpress.com/
✑ dgkim84 @ twitter / fb
2
데이터 엔지니어, 분석가
안드로이드, iOS 앱 개발자
백엔드, 웹 프론트엔드 개발자
충원 중 입니다.
https://github.com/lezhin/apply/
blob/master/README.md
3. Google Cloud Platform
GCP에 더 많은 제품이 있지만, 데이터팀에서 사용하고 있는 주요 제품군
3
https://cloud.google.com/icons/
우리 팀은 저 뿐인 팀이고 다 외주 직원들로 구성 얼굴 본 적은 없지만 그 분들
이 제품을 만들어줍니다.
로그 수집, 가공, 적재, 모델링, 분석 등을 할 수 있도록 지원해주고 있습니다.
BigData 제품군, Compute 제품군, 로깅, 네트워크, 스토리지 등 제품군을 활용
중 입니다.
BigTable 과 같은 제품들도 작지만 사용 중에 있습니다.
4. 왜
레진코믹스 데이터팀은
GCP 를 선택했나
4
https://www.slideshare.net/curioe_/lezhincomics-google-appengine-30453946
왜 레진코믹스는 구글앱엔진을 선택했나
5. 안정적이고 독립된
Data Infrastructure
- 2016년 4월 탈출
5
본업은 백엔드팀 이었고 업무 외에 작업이 진행된 것 이기때문에
손이 덜 가고 안정적으로 운영되도록 하는게 주 목표입니다.
그렇기때문에 오픈소스와 같은 제품을 직접 운영하는 것보다 fully managed 되
고 있는 GCP 제품군을 더 살펴보게 됩니다.
6. Google Cloud Platform
더 많은 제품이 있지만, 데이터팀에서 사용하고 있는 주요 제품군.
6
수집 -> 가공 -> 적재 -> 모델링 -> 분석
수집 -> 가공 -> 적재 -> 모델링 -> 분석 등의 과정을 거치면서
마케팅, 빌링, 기획팀 등에서 SQL 등을 활용할 수 있도록 DWH 구축부터
BI 툴 연계를 통해 SQL을 다루지 못하는 분들도 시각화 할 수 있는 툴을 제공합
니다.
이 인프라로 한달에 대략 10억건 이상의 유의미한 로그가 쌓입니다.
배치 분석을 위해 스토리지로, 실시간 분석을 위해 Pub/Sub 등으로 보내집니다.
대부분의 ETL과 추천처리는 Spark 로 이루어지며 실시간 처리는 DataFlow
Streaming 쓰고 배치도 씁니다.
7. GCP 기능 외에
필요한 것
- 워크플로우 & 스케쥴러
- 추천(검색) 데이터 서빙용 어플리케이션 서버
- 서비스 특화된 지표용 백오피스
- 기타 수 많은 어플리케이션 서버
7
워크플로우 & 스케쥴러 : Airflow (Oozie, Azkaban, Luigi 와 같은) 제품으로
ETL 잡이나 이런 반복되는 작업을 DAG 형태로 관리하고 스케쥴링하는 역할
이와 같은 역할을 해주는 서버들이 있는데 관리를 효율적으로 하려고 할 때
고민하는 사항들이 있습니다.
8. Checklist
✑ Deployment
✑ Provisioning
✑ Automation
✑ Stateless, Stateful
✑ Scalability
✑ Monitoring
✑ Discovering Service
8
배포, 프로비저닝, 자동화 등이 그것이고
확장성이라던지 모니터링 그리고 Discovering Service 와 같은 문제들이 있습니
다.
이걸 개별로 구축하고 관리하는 비용은 어찌보면 굉장히 큽니다.
이번 발표에서는 자동화, Stateful 어플리케이션에대한 문제, 모니터링,
Discovering Service에대한 상세한 내용은 시간관계상 다루지 못합니다.
12. Pod
✑ 배포 최소 단위
✑ 하나 이상의 container (docker / rkt) 포함
✑ 함께 포함시켜야 할 것이 있다면 함께 선언
✑ Resources
✑ Volumes, Port, …
✑ CPU, Memory
✑ Request, Limit
✑ livenessProbe
✑ …
✑ Unique IP address
12
rkt (rock-it) 은 experimental
함께 포함시켜야할 것이 있을 때 함께 선언합니다.
기본적으로 container 기반이기때문에 OS나 dependency 문제는 쉽게 해결이 됩니다.
여기서 가장 중요한 것은 hello world 수준의 guide에선 언급이 안되지만
resource 관리가 중요하며, Pod은 Kubernetes에서 가장 작은 개념으로 알려져있지만
가장 다루기 어렵고 중요한 대상입니다. 삽질해보시면 알게됩니다.
진짜! 그렇기때문에 Kubernetes는 학습해야할 것이 적지 않습니다.
14. QoS
✑ Guaranteed
✑ Limits OR Limits = Requests
✑ Burstable
✑ Limits not set OR Requests != Limits
✑ Guaranteed and Best-Effort = Burstable
✑ Burstable and Best-Effort = Burstable
✑ Best-Effort
✑ Requests, Limits 모두 설정 안된 경우
✑ 이를 바탕으로 oom_score_adjust 결정
✑ 중요한 것이 먼저 kill 될 수 있으니 Resources 설정 중요.
14
Pod은 2개 이상의 container를 가질 수 있기때문에
Guaranteed 가 있더라도 Burstable 로 분류될 수 있습니
다.
15. Expose
✑ $ kubectl expose
✑ pod/airflow-web
✑ —namespace dev
✑ —port=8080
✑ —target-port=8080
✑ —type=LoadBalancer
✑ $ kubectl get service —namespace dev
✑ $ open http://EXTERNAL_IP:8080/
15
외부로 노출하기위해선 expose가 필요합니다.
—type 을 별도로 기록하지 않으면 ClusterIP가 생성됩니
다.
HTTP LoadBalancer는 Ingress Object Model 통해서 하
며 이 발표에서는 자세히 언급되지 않습니다.
22. Kubernetes Deployment
✑ Newer and Higher level concept (since 1.2)
✑ ReplicaSet, ReplicationController
✑ Pods, ReplicaSet 등 리소스를 생성하고 기존의 것을
바꾸는 등 일련의 작업을 명시합니다.
✑ Replica, Autoscaling
✑ Rolling Update, Rolling Back
✑ PodTemplate
22
Deployment 가 알아서 해주기때문에 Pod이나 ReplicaSet 등의 리소
스 생성에대해 크게 고민하실 필요는 없습니다.
기본적으로 명시하는 것들은 replica 랑 update strategy 정도이구요.
생성한 deployment 로 autoscale, rolling update, rollout 등을 수행
할 수 있습니다.
Deployment에도 생성할 Pod에대한 기본 Template을 명세합니다.
31. Scale
✑ $ kubectl scale —namespace dev
✑ —replicas=3 deploy/af-worker
✑ 현재 replica가 2개일 때만 적용하고 싶을 땐,
✑ $ kubectl scale —namespace dev
✑ —replicas=3 —current-replicas=2 deploy/af-worker
31
32. Horizontal Pod Autoscaling
since 1.2
✑ stable 버전에선 cpu만 지원
✑ $ kubectl autoscale
✑ deploy/af-worker
✑ —cpu-percent=60 —min=1 —max=4
✑ $ kubectl get hpa
✑ autoscaling/v2alpha1 에서 더 다양하게 제어 가능해집니다.
✑ memory, multiple custom metrics
32
34. Scalability
✑ Scale up/down
✑ Assigning Pods to Nodes
✑ Attach label to the node
✑ Add a nodeSelector field to Pod spec
34
35. Node Pool
✑ $ gcloud container node-pools create NAME
✑ —zone ZONE --cluster CLUSTER
✑ —machine-type n1-standard-4
✑ —num-nodes 3
35
36. Preemptible Node Pool
✑ $ gcloud beta container node-pools create NAME
✑ —zone ZONE --cluster CLUSTER
✑ —machine-type n1-standard-4
✑ —num-nodes 3
✑ —preemptible
✑ $ kubectl get nodes
✑ —selector='cloud.google.com/gke-preemptible'
✑ $ kubectl get nodes
✑ —selector='!cloud.google.com/gke-preemptible'
36
저렴한 가격으로 클러스터를 운영해봅시다.
근데 중요한 POD이 preemptible에 올라가면 어떻게
될까요…
Pod을 특정 노드에 할당되도록 알아봅시다.
37. Label
✑ 모든 resource에 label 추가/삭제 가능
✑ $ kubectl label node NODE_NAME
✑ —overwrite key=value
✑ Removing a label
✑ $ kubectl label node NODE_NAME key-
37
NodeSelector 를 언급하기 전에 각 리소스 (node, pod, …)에 Label을 달 수 있습니다.
39. Blue-Green Deployment /1
39
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
labels:
color: green || blue
app: af-web
name: af-web-green || af-web-blue
spec:
replicas: 1
template:
metadata:
labels:
color: green || blue
app: af-web
Deployment 를 두개를 배포합니다.
하나는 blue 또 다른 하나는 green 으로 합니다.
전체를 한번에 다른 버전으로 route
시켜보도록 하겠습니다.
40. Blue-Green Deployment /2
40
spec:
ports:
- nodePort: 32354
port: 8080
protocol: TCP
targetPort: 8080
selector:
color: green
app: af-web
type: LoadBalancer
apiVersion: v1
kind: Service
metadata:
labels:
run: af-web
name: af-web
Expose 하면 기본적으로 Service 하나 만들어집니다.
$ kubectl get services
$ kubectl edit service/<SERVICE_NAME>
한 다음 설정처럼 selector 값을 조정해서 새롭게 배포한 곳으로 가도록
할 수 있습니다.