Offcanvas
Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.
Offcanvas
1111Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.

도커

글로벌 칼럼 | 컨테이너 기반 통합 테스트의 이점

완벽한 소프트웨어를 가진 행성이 어딘가에 있을 수 있지만, 구글의 오픈소스 책임자 크리스 디보나의 말처럼 우리가 사는 행성은 그런 행성이 아니다. 따라서 개발자에게는 2가지 길이 있다. 소프트웨어를 신중하고 엄격하게 테스트해 발생할 수 있는 모든 문제를 배포 전에 찾아내거나, 테스트를 줄이고 배포 속도를 높여 프로덕션 환경에서의 오류를 감내하는 것이다.   전자는 의료 및 금융 같은 규제 산업에서 일하는 개발자가 주로 택하는 길이며, 후자는 “개발한 사람이 운영까지 한다(You build it, you run it)”라는 AWS CTO 베르너 보겔스의 유명한 격언에 동의하는 개발자가 선택하는 길이다.  이처럼 소프트웨어 테스트와 배포 속도 사이의 균형은 개발자의 생산성과 관련한 대표적인 논쟁거리다. 테스트 어느 단계에 있든, 소프트웨어 테스트를 위한 단일화된 솔루션은 없다. 때문에 개발자는 변화하는 요구사항에 맞춰 올바른 테스트 방법을 지속해서 모색해야 한다. 동시에 개발자는 사용할 테스트 방법을 습관으로 만들기 위해 느리거나 복잡하지 않으면서 주요 문제를 해결하는 가장 효율적인 방식을 찾아야 한다. 최근 필자는 ‘유닛 테스트’에서 효율적인 방식을 발견했다. 유닛 테스트는 독립적으로 진행하는 가장 작은 단위의 소프트웨어 테스트다. 소프트웨어가 의도에 따라 동작하는지 확인할 수 있을 뿐 아니라 다른 개발자가 작성한 코드 베이스의 일부를 추론할 수도 있다. 유닛 테스트는 오래 전부터 사용하던 방법이지만, 최근 들어 자동화가 사용자 경험을 실제 사용성까지 단순화하면서 깊숙이 자리 잡았다. 유닛 테스트와 유사한 다른 형태의 테스트 방법도 있다. 수십 년 동안 개발 중인 방법이지만, 이제서야 본질적인 문제를 해결하고 단순화된 접근에 적절한 추상화 수준을 제공하며 효율적인 방식을 찾아가고 있는 ‘통합 테스트’다.  개발자의 역할은 ‘조립’에 있다 전통적인 3계층 아키텍처 시스템은 데이터베이스 1개와 상호작용할 수 있는 API를 1...

컨테이너 도커 통합테스트 4일 전

도커와 젠킨스로 시작하는 실전 CI/CD 구현 가이드 - IDG DeepDive

젠킨스(Jenkins)는 다른 일상적인 개발 작업을 자동화할 뿐 아니라 파이프라인에 걸쳐 거의 모든 언어의 조합과 소스코드 리포지토리에 대한 지속적 통합/지속적 배포(CI/CD) 환경을 구축하는 직관적인 방법을 제공한다. 단계별 스크립트는 여전히 작성해야 하지만, 사용자가 더 빠르고 강력하게 빌드, 테스트, 그리고 배포 등 체인 전체를 통합할 수 있다. 도커와 젠킨스, CI/CD의 개념을 알아보고, 이를 이용해 직접 CI/CD를 구현하는 과정을 차근차근 설명한다. 주요 내용 - “빌드·테스트·배포의 통합” 젠킨스와 CI 서버의 이해 - 젠킨스를 이용한 '지속적 통합' 구축 실전 - 도커와 젠킨스로 CI를 구현하는 방법

도커 젠킨스 CI 2022.01.12

'도커 이전과 도커 이후' 세상이 확연히 달라진 이유

2013년 도커는 화제의 ‘바로 그’ 회사였다. 컨테이너가 주류로 부상하는 데에 결정적 역할을 하면서 신문 1면을 장식했고, 많은 분야에서 PaaS를 밀어내고 당대 최고의 인기 기술로 자리잡았다(헤로쿠(Heroku)를 기억하는 사람이 지금도 있을까?). 그리고 이제 도커는 유료 요금제 방식의 도커 데스크톱(Docker Desktop) 모델로 다시 언론의 주목을 받고 있다. 이번 발표에 대한 격렬한 반응을 보면, 도커로 인해 현재 널리 사용되는 주류 모델인 컨테이너의 인기가 얼마나 높아질 수 있었는지 다시금 상기하게 된다.   도커는 컨테이너를 발명한 곳이 아니라, 오픈소스 도구와 재사용 가능한 이미지로 컨테이너 기술의 접근성을 높인 회사다. 도커를 사용하면 개발자는 소프트웨어를 한 번만 만들어서 로컬 또는 프로덕션 서버에서 실행할 수 있다.     도커 명령줄 도구가 몇 년 동안 사용된 화려한 웹 인터페이스를 밀어냈다는 사실은 개발자가 진정으로 원하는 것이 무엇인지를 잘 보여주는 사례일 것이다. 그러나 도커가 미친 영향을 제대로 이해하기 위해서는 도커 컨테이너 기술이 등장하기 직전의 상황을 되짚어보는 것이 중요하다.   그 다음 혁신에 대한 갈증 2009년은 가상화에서 얻는 가치가 널리 인식되고, 구현도 폭넓게 이루어진 시기다. 대다수 조직이 이미 가상화의 혜택을 얻었거나 그런 수준에 이르기 위한 로드맵을 두고 있었다. 가상화 이야기를 질리도록 들은 사람들은 IT와 소프트웨어 개발의 다음 혁신에 목말라 있었다. 그때 등장한 것이 헤로쿠다. 일반적인 PaaS와 헤로쿠는 큰 인기를 얻었다. 마치 PaaS가 세상을 정복할 듯한 분위기였다.   당시 헤로쿠는 대단했다. 헤로쿠 포털에서 앱을 개발하고 바로 서비스로 제공한다? 그걸 마다할 이유가 있을까? 헤로쿠에서 앱을 개발하지 않을 이유는 전혀 없는 것만 같았다.   그런데 시간이 지나고 보니, 헤로쿠 같은 PaaS 플랫폼을 사용하지 않을 만한 이유가 몇 가지 있...

도커 컨테이너 2021.11.18

'실전 예제로 보는' 자바 개발에서의 도커 사용법

개발 중 도커(Docker)를 사용할 때 얻는 이점은 개발 기기와 다양한 환경(QA, 프로덕션 등)에 걸쳐 일관적인 테스트 환경을 제공할 수 있다는 것이다. 반면 어려운 점도 있다. 도커 컨테이너로 인해 개발자가 코딩 중 관리해야 하는 부가적인 추상화 계층이 발생한다.  도커를 이용하면 애플리케이션 코드를 시스템 요구사항 정의와 함께 여러 플랫폼에서 실행 가능한 패키지로 묶을 수 있다. 소프트웨어 런타임 배포와 관리에서 근본적으로 필요한 부분을 해결하는 효과적인 추상화지만, 대신 프로그래머가 대처해야 하는 부가적인 간접성 계층이 발생해 소프트웨어와 그 종속 항목의 내부 구조를 반복적으로 수정하고 테스트해야 한다. 이러한 개발 속도 저하는 개발자가 가장 피하고 싶어하는 일이다. 이를 둘러싼 다양한 찬반 양론이 있다.   개발 기기 전반에서 본격적으로 도커를 사용하지 않는다고 해도 컨테이너 내에서 실행되는 코드를 수정, 디버깅하는 다양한 사례가 있다. 예를 들어 개발자는 도커를 사용해 프로덕션 환경을 똑같이 만들어 오류 또는 기타 조건을 재현할 수 있다. 또한 도커화된 앱을 실행하는 호스트에 대한 원격 디버깅 기능은 QA와 같이 실행 중인 환경에 대한 직접적인 문제 해결을 가능하게 해준다.  여기서는 구글 클라우드 플랫폼(GCP)에서 VM에 간단한 자바 앱을 만들어서 도커화한 다음 원격으로 디버깅하고, 로컬 호스트의 비주얼 스튜디오 코드에서 앱 코드를 수정하는 과정을 살펴보자. 실행할 2가지 중요한 작업은 컨테이너를 재시작하지 않고 실행 중인 코드베이스 업데이트하기, 그리고 실행 중인 컨테이너화된 앱 디버깅하기다. 또한 이 프로세스를 원격으로 실행되는 컨테이너에서 수행한다. 즉, 로컬 개발 호스트 외에 QA 서버와 같은 서비스를 원격으로 디버깅하는 방법도 살펴본다.   자바와 스프링 부트 설정하기 시작 지점은 GCP 콘솔이다(계정이 없다면 무료 계정 가입). 컴퓨트 엔진(Compute Engine) 링크로 이동하면 VM...

자바 도커 docker 2021.11.10

도커와 젠킨스를 이용해 지속적 통합을 구현하는 방법

지속적 통합과 지속적 제공(CI/CD)을 구현하는 방법은 다양하지만, 여러 이유로 보통은 도커(Docker)와 같은 컨테이너 앱을 사용한다. 컨테이너화가 이뤄진 후에 CI 파이프라인에 중요한 요소는 체크인 시 이미지를 빌드하고 테스트를 실행한 다음 후속 단계에서 사용하기 위해 도커 허브(Docker Hub) 또는 다른 레지스트리에 이 이미지를 게시하는 것이다.    젠킨스(Jenkins)를 설정해 깃허브에서 업데이트된 애플리케이션 코드를 가져와 도커 이미지를 빌드하고 테스트를 실행하고 레지스트리에 게시하는 방법을 살펴보자. 여기서는 간단한 자바 앱을 사용하지만 다른 스택에서도 과정은 대체로 비슷하다.    도커 허브에 게시하기 자바, 젠킨스, 도커의 기본적인 사항은 이 기사를 참고하고, 여기서는 한 걸음 더 나아가 최신 깃허브 체크인을 가져오고 앱의 도커 이미지를 빌드하고 이를 도커 허브에 게시하는 방법을 알아보자. 무료인 도커 허브 계정이 필요하다.  중앙 컨테이너 이미지 리포지토리(이 경우 도커 허브)에 게시하는 것은 기업 CI/CD의 핵심 요소다. QA에서 테스트, 프로덕션에 이르는 다양한 단계에서 아티팩트를 재사용하기 위한 공통된 장소가 바로 이미지 리포지토리이기 때문이다.   젠킨스와 도커-인-도커 실행하기 도커를 실행하도록 젠킨스를 설정하기 위해 VM에서 도커 이미지 2개를 실행한다. 한 컨테이너는 도커 자체에서 액세스하기 위한 '도커-인-도커'(docker:dind 이미지)를 호스팅하고, 다른 하나는 젠킨스를 호스팅한다. 두 컨테이너는 네트워크와 볼륨을 통해 상호작용한다. 이런 방식은 젠킨스 안내서에서 권장하는 방법이기도 하다. 먼저 원하는 클라우드 서비스에서 새 VM을 만든다. 여기서는 구글 클라우드 플랫폼(GCP)을 사용한다. 이 아키텍처를 빠르게 시작하는 방법은 도커와 도커-인-도커 이미지를 이미 설치된 VM으로 시작하는 것이다. GCP 콘솔에서 컴퓨트 엔진(Compute Engin...

도커 젠킨스 지속적통합 2021.10.27

"컨테이너 혁명을 주도하는" 도커의 의미와 장단점

도커(Docker)는 컨테이너에 기반해 애플리케이션을 구축하는 소프트웨어 플랫폼이다. 컨테이너는 운영체제 커널을 공유하지만, 그 외의 경우 서로 격리되어 실행되는 작고 경량의 실행 환경이다. 컨테이너는 리눅스와 유닉스에서 상당 기간 사용됐다. 그러나 2013년 시작된 오픈소스 프로젝트인 도커가 컨테이너 기술을 보편화하는 데 기여했다. 도커에 의해 개발자가 소프트웨어를 패키징 해 ‘한번 구축하면 어디서나 실행할 수 있는(build once and run anywhere)’ 것이 어느 때보다 더 쉬워졌다.     도커의 역사 요약  2008년 솔로몬 하익스가 프랑스 파리에서 닷클라우드(DotCloud)라는 이름으로 설립한 도커는 원래 서비스 플랫폼(platform as a service, PaaS)로서 시작했다. 이후 2013년 플랫폼이 실행되는 기저의 소프트웨어 컨테이너를 보편화하는 것으로 초점이 변화했다.   하익스는 2013년 3월 파이콘(PyCon)에서 도커를 처음 선보였다. 하익스는 도커가 닷클라우드 플랫폼(서비스 플랫폼)을 구동할 기저 기술에 대한 개발자들의 끊임없는 요구를 반영해 개발됐다고 설명했다. 그는 “이 기저 기술이 있다면 리눅스 컨테이너로 무엇이든 할 수 있다. 자체적인 플랫폼을 만들 수 있다. 이게 우리가 하고 있는 것이다”라고 말했다.  그래서 도커가 탄생했다. 이 오픈소스 프로젝트는 개발자들을 신속히 끌어들였고 유명한 IT 업체인 마이크로소프트, IBM, 레드햇 등이 관심을 보였다. 그리고 벤처 투자자들은 이 혁신적인 스타트업에 수백만 달러를 투입할 용의가 있었다. 이렇게 컨테이너 혁명이 시작됐다.  컨테이너란 무엇인가?  하익스가 파이콘에서 설명한 것처럼 컨테이너는 ‘독립형 소프트웨어 단위(self-contained units of software)’로서 서버로부터 서버, 노트북으로부터 EC2, 베어-메탈 자이언트 서버로 전달될 수 있다. 그리고 이는 프로세스 수준에...

도커 Docker 컨테이너 2021.08.04

사일로스케이프, 윈도우 컨테이너 넘어 쿠버네티스 클러스터에 백도어 설치

클라우드 컨테이너를 대상으로 한 악성코드 공격은 새롭지는 않지만 지금까지는 리눅스 환경을 집중적으로 노렸다. 리눅스가 가장 보편적인 운영체제이며, 컨테이너가 탄생한 곳이기도 하기 때문이다. 그런데 이제는 윈도우의 도커(Docker) 환경을 표적으로 하는 공격이 일어나고 있다. 윈도우 서버 컨테이너에서 벗어나 쿠버네티스(Kubernetes) 클러스터를 감염시키도록 만들어진 새로운 악성코드 프로그램이 발견됐다. 사일로스케이프(Siloscape)로 불리는 이 악성코드는 상당한 수준으로 난독화되어 있으며, 거의 알려지지 않은 윈도우 컨테이너 이스케이프 기법을 사용하고 명령 제어 통신에는 토어(Tor)를 사용한다. 사일로스케이프의 목적은 쿠버네티스 노드와 클러스터에 대한 접근 권한을 획득한 후 공격자의 후속 명령을 대기하는 것이다. 도커 및 윈도우 서버 컨테이너 도커와 쿠버네티스는 클라우드 인프라에 컨테이너화된 애플리케이션을 배포하기 위한 주된 기술이다. 또한 현대 소프트웨어 개발에서 마이크로서비스 아키텍처의 인기를 이끈 직접적인 이유이기도 하다. 마이크로서비스 아키텍처에서는 소프트웨어가 각자의 안전한 컨테이너에서 독립적으로 실행되는, 느슨하게 결합된 복수의 서비스로 분할된다. 도커는 컨테이너를 설정하는 데 사용되는 기술로, 리눅스 커널에 탑재된 커널 기반 가상화 기능을 기본으로 한다. 쿠버네티스는 네트워크(클러스터)로 그룹화되는 여러 호스트(노드)에 걸쳐 이러한 컨테이너와 컨테이너 안에서 실행되는 애플리케이션을 관리하는 데 사용된다. 두 플랫폼이 소프트웨어 개발과 배포에서 엄청난 인기를 끌자 마이크로소프트는 윈도우 서버에서도 도커와 쿠버네티스 실행이 가능하기를 원했지만 리눅스에서 컨테이너가 동일한 커널을 공유할 수 있게 해주는 몇몇 프로세스와 파일시스템 격리 기능이 윈도우 커널에는 없었다. 마이크로소프트는 이런 기능 가운데 일부를 개발해 윈도우 서버 2016에 처음으로 통합해 윈도우 컨테이너라는 기능을 구현했다. 윈도우 컨테이너는 2가지 격리 모드를 지원...

사일로스케이프 윈도우 컨테이너 2021.06.15

도커 허브, 절반 이상이 심각한 취약점을 갖고 있다

최근 도커 허브(Docker Hub) 리포지토리에 호스팅 된 400만 개의 컨테이너 이미지를 보안 분석한 결과에 따르면, 절반 이상의 이미지에 최소 1개 이상의 중대한 취약점이 포함되어 있는 것으로 드러났다. 수많은 이미지에 악성코드나 잠재적으로 유해한 애플리케이션이 포함되어 있었다. 이는 기업이 퍼블릭 리포지토리에서 컨테이너 이미지와 서드파티 소프트웨어 구성요소를 소싱할 때 엄격한 정책과 평가 프로세스를 적용해야 한다는 것을 의미한다.  소프트웨어 공급망을 악용하는 공격은 새롭지 않다. 그러나 컨테이너 기술에 토대를 둔 마이크로서비스(microservice) 기반 소프트웨어, 애자일(agile) 개발, 데브옵스(DevOps)의 인기가 높아지면서 선제작(pre-made)된 소프트웨어 구성요소와 이미지를 호스팅한 퍼블릭 레지스트리(리포지토리)의 성장을 촉발했다. 그 결과, 공격자들은 이런 상관관계를 악용하려고 시도하고 있다. 직접, 또는 기존 계정을 침해하는 방법으로 이런 패키지 리포지토리에 악성코드를 게시하고 있는 것이다. 오픈소스 거버넌스 업체인 소나타입(Sonatype)은 ‘2020 소프트웨어 공급망 현황(State of the Software Supply Chain)’ 보고서에서 복잡한 종속성을 악용해 오픈소스 소프트웨어 프로젝트 업스트림의 침입을 시도하는 공격이 지난해에 비해 430% 증가했다고 보고했다.  이런 공격들 가운데 상당수는 악성코드 배포에 퍼블릭 패키지 리포지토리를 악용했다. 예를 들어, 자바스크립트 생태계는 npm, 파이썬 개발자 생태계는 PyPi를 이용했다. 개별 소프트웨어 패키지가 아닌 선구축(pre-built)된 컨테이너 배포에 이용되는 도커 허브조차 예외가 아니다. 소나타입 보고서에 따르면, 지난해 도커 허브에는 220만 개의 컨테이너 이미지가 추가됐고, 올해 개발자들로부터 960억 건의 이미지 풀 요청을 받았다. 취약한 도커 이미지, 51%에 달해  도커 같은 컨테이너 기술은 기업이 애플리케...

도커 취약점 2020.12.04

"컨테이너 구현 관리, 서비스 형태로 성장한다" CaaS의 이점과 가능성

현대적으로 컨테이너화된 애플리케이션의 인기가 계속 높아지고 있다. 주요 업체가 컨테이너 인프라 및 관리를 서비스 형태로 제공하게 되는 것도 시간 문제일 뿐인 것 같다. 컨테이너는 전 세계 기업 시장에서 확고한 성장세를 기록하고 있다. 플렉세라(Flexera)의 최신 2020 클라우드 현황 보고서에 따르면 조직의 65%가 도커 컨테이너를 사용 중이며 58%는 쿠버네티스 오케스트레이션 시스템을 사용하고 있다. 컨테이너를 사용해서 애플리케이션을 구축하고 유지하는 데 있어 가장 큰 과제로 꼽히는 요소는 리소스와 전문 기술의 부족이다. 따라서 갈수록 많은 개발자들이 서비스형 컨테이너(CaaS)가 제공하는 자동화를 선택하고 있다. CaaS 시장은 현재 3개 주요 클라우드 업체가 주도하고 있다.     서비스형 컨테이너, 또는 CaaS란? CaaS에서 클라우드 업체는 큰 인기를 누리는 쿠버네티스 오픈소스 프로젝트(구글에서 시작된 프로젝트)를 기반으로 호스팅되는 컨테이너 오케스트레이션 엔진을 제공하여 컨테이너를 배포 및 실행하고 클러스터를 관리하고 확장과 장애 관리를 자동화하고 포함된 거버넌스 및 보안 기능을 통해 공통 인프라 계층을 유지한다. 일반적으로 모든 네트워크, 부하 분산, 모니터링, 로깅, 인증, 보안, 자동 확장, 지속적 통합/지속적 제공(CI/CD) 기능을 CaaS 플랫폼이 담당한다. CaaS를 사용하는 조직은 클라우드 인프라의 이점을 활용하는 동시에 AWS 엘라스틱 빈스토크(Elastic Beanstalk), 애저 앱 서비스, 구글 앱 엔진과 같은 일반적인 서비스형 플랫폼(Paas)에 수반되는 업체 종속도 피할 수 있다. 컨테이너 자체가 다양한 환경 전반에서 간단한 이식성을 구현하기 때문이다. 컨테이너로 방향을 정했다면 CaaS와 일반적인 서비스형 인프라(IaaS)에서 실행하는 방법 간의 차이점을 알아야 한다. 둘의 차이는 조직에 쿠버네티스(또는 다른 컨테이너 오케스트레이션 계층) 자체를 구현하고 관리하기 위한 리소스와 기술이 ...

컨테이너 퍼블릭클라우드 AWS 2020.07.30

흔히 저지르는 컨테이너 보안 실수 6가지와 예방법

클라우드로 데이터와 워크로드를 옮기는 조직이 늘어나면서 컨테이너에 대한 의존도도 높아지고 있다. 컨테이너는 애플리케이션을 다른 컴퓨팅 환경으로 옮기더라도 안정적으로 실행되도록 코드와 그 종속성을 패키지화한 소프트웨어 유닛이다. 미국 클렘슨대학 유전 및 생화학 학부 소속 클라우드 아키텍트인 콜 맥나이트는 컨테이너화는 애플리케이션과 서비스를 안전하게 배포하기 위한 견고한 기술로 부상했다고 말했다.   맥나이트는 도커(Docker), 싱귤러리티(Singularity)와 같은 컨테이너 엔진은 안전한 설치 책임을 개별 사용자에게 맡기는 대신 특정 애플리케이션을 위한 최선의 보안 정책을 구현하고 배포하는 수단을 제공한다면서 “쿠버네티스, 메소스, 도커 스웜과 같은 컨테이너 오케스트레이션 플랫폼은 컨테이너 배포와 실행에 특화된 보안 메커니즘을 통합했다. 그 결과, 쉽게 구성할 수 있는 컨테이너 개발 및 배포 생태계가 형성됐다”라고 말했다. 이와 같은 기술은 안전한 애플리케이션과 서비스를 제공하는 데 일반적으로 따르는 복잡성을 많은 부분 걷어내지만, 맥나이트는 개발팀이 이런 보안의 가능성을 보안을 보장하는 것으로 해석하는 경우가 있다고 지적했다. 문제는 컨테이너 구현 과정에서 실수를 할 수 있다는 것이다. 컨테이너를 사용하는 팀이 이러한 실수를 저지르면 보안 문제를 해결하는 게 아니라 오히려 유발하게 된다.   1. 컨테이너 자체에 지나치게 집중한다 맥나이트는 “안전한 컨테이너를 구현할 때 발생하는 가장 흔한 실수는 컨테이너 자체에 온전히 초점을 맞추는 것”이라고 말했다. 이미지의 보안을 위한 베스트 프랙티스를 유지하는 것도 중요하지만 개발자가 이미지가 실행되는 환경을 고려하지 않고 이미지의 보안에만 골몰하는 경우가 적지 않다. 맥나이트는 “컨테이너 내부의 보안이 아무리 강력해도 호스트의 컨테이너 악용으로부터 보호할 수는 없다. 컨테이너 엔진을 호스팅하는 각 시스템을 일반적으로 악용 가능한 취약점에 대비해 각 계층에서 보호해야 한다”고 강조했다. ...

호스트 컨테이너 도커 2020.05.11

“기업 78%가 도입” 쿠버네티스의 성공 비결

컨테이너 오케스트레이션 플랫폼 쿠버네티스가 첫 커밋 후 1년 만인 2015년 중반에서야 1.0에 도달했다는 사실은 믿기 힘들다. 이제 쿠버네티스는 CNCF(Cloud Native Computing Foundation)의 설문조사 대상 기업 중 78%가 활용하고 있기 때문이다. 미친 듯이 빠른 도입이다. CNCF 2018년도 보고서에 따르면, 불과 1년 전에 쿠버네티스 활용 기업 비율은 58%였다.  애플리케이션 개발 방식 개선에 나선 기업 입장에서 컨테이너가 얼마나 큰 힘을 발휘하는지 알 수 있는 대목이다. 또 광범위한 기술 도입에 오픈소스가 얼마나 중요해졌는지도 알 수 있다.     쿠버네티스 커뮤니티 쿠버네티스 인기의 비결은 잘 알려져 있다시피 커뮤니티이다. 필자가 2016년 지적한 것처럼, 쿠버네티스는 최초의 컨테이너 오케스트레이션 솔루션은 아니다. 최초 출시의 영광은 메조피어와 도커가 누리고 있다. 또 시중에 나와 있는 유일한 오픈소스 컨테이너 오케스트레이션 툴도 아니었다. 오히려 비결은 개방성이었다. 오픈소스이면서도 통제 방식이 폐쇄적이어서 장래의 기여자들(그리고 경쟁자들)을 좌절시키는 경우가 있다. 그러나 구글은 색다른 전술을 취했다. 이에 대해 당시에 필자는 다음과 같이 적은 바 있다.   “[쿠버네티스, 도커, 그리고 아파치 메조 간에] 커뮤니티 결과가 이렇게 크게 다른 것을 무엇으로 설명할까? 한마디로 구글이다. 아니면 구글의 상대적인 부재라고 할 수도 있다. 다른 오케스트레이션 프로젝트는 저마다 한 업체의 영향을 크게 받는 데 반해, 쿠버네티스는 구글의 독창적인 엔지니어링은 물론, 지속적인 개발에 대한 구글의 무간섭 방식의 덕을 보고 있다.” 5년이 지난 지금 구글은 여전히 쿠버네티스에 가장 큰 기여자이며, 그 뒤를 VM웨어와 레드햇이 따르고 있다. 그러나 쿠버네티스에 오직 구글뿐이었던 시절은 지나갔다. 이제는 어림도 없다. 2,000곳 이상의 업체에 퍼져 있는 3만 5,000명이 넘는 기여자들이 1...

커뮤니티 컨테이너 도커 2020.03.10

쿠버네티스와 도커를 백업하는 방법

컨테이너 인프라에도 일종의 백업이 필요하다. 재해가 발생한 후 쿠버네티스와 도커가 스스로 재건되지는 않기 때문이다. 각 컨테이너의 실행 상태를 백업할 필요는 없지만 컨테이너를 실행하고 관리하는 데 사용되는 구성은 백업해야 한다. 백업해야 할 요소를 간단히 요약해 보자.   구성과 원하는 상태 정보 이미지를 만드는 데 사용되는 도커파일(Dockerfile)과 이 파일의 모든 버전 도커파일에서 생성되어 각 컨테이너를 실행하는 데 사용되는 이미지 쿠버네티스 etcd 및 기타 : 클러스터 상태에 대한 정보를 저장하는 K8s 데이터베이스 배치 : 각 배치를 설명하는 YAML 파일 컨테이너에 의해 생성 또는 변경되는 영구 데이터 영구 볼륨 데이터베이스   도커파일 도커 컨테이너는 이미지에서 실행되며, 이미지는 도커파일에서 작성된다. 적절한 도커 구성이라면 일반적으로 깃허브와 같은 리포지토리를 모든 도커파일의 버전 제어 시스템으로 사용한다. 애드혹 도커파일로 만든 애드혹 이미지를 사용해서 애드혹 컨테이너를 만들어서는 안 된다. 모든 도커파일은 현재 빌드에서 문제 발생 시 과거 버전을 가져올 수 있는 기능을 제공하는 리포지토리에 저장해야 한다. 또한 각 K8s 배치와 연결된 YAML 파일을 저장할 리포지토리도 필요하다. 이와 같은 YAML 파일은 버전 제어 시스템을 활용할 수 있는 텍스트 파일이다. 백업해야 할 대상은 이 리포지토리다. 가장 많이 사용되는 리포지토리 중 하나는 깃허브다. 깃허브는 리포지토리를 백업할 수 있는 여러 가지 방법을 제공한다. 제공된 API를 사용해서 리포지토리의 현재 백업을 다운로드하는 다양한 스크립트가 있고, 깃허브나 기타 사용 중인 리포지토리를 백업하기 위한 별도의 상용 툴도 있다. 이런 권장사항과 달리 도커파일이 더 이상 없는 이미지를 기반으로 컨테이너를 실행 중이라면, docker image history 명령, 또는 dfimage와 같은 툴을 사용해서 현재 이미지에서 도커파일을 만들 수 ...

백업 컨테이너 도커 2020.01.20

2020년에 주목해야 할 5가지 마이크로소프트 개발자 툴과 기술

2020년이 막 시작된 지금이라도 애플리케이션 개발 계획과 기술 로드맵을 구상하기 위해 앞을 내다봐야 한다. 지난 몇 년 동안 마이크로소프트의 여러 플랫폼에서 애플리케이션을 구축하는 모든 사람에게 많은 변화가 일어났는데, 앞으로도 변화는 계속된다.   2020년에는 무엇을 주목해야 하고 그 이유는 무엇인가? 윈도우와 애저를 비롯한 여러 분야의 5가지 옵션을 살펴보자. 이 5개가 전부는 아니지만 더 현대적인 개발 플랫폼과 툴 모음을 향한 길의 시작 지점이다. 닷넷 5로 전환 시작 닷넷 코드를 작성하는 모든 사람들이 직면하는 가장 큰 과제는 2020년 말에 닷넷 5 출시와 함께 시작될 오래된 닷넷 프레임워크에서 닷넷 코어로의 전환이다. 두 개의 닷넷 가지를 하나로 묶는 것은 일부 오래된 API를 잃는다 해도 타당한 조치다. 마이크로소프트는 닷넷 깃허브 리포지토리에 전환되는 요소와 전환되지 않는 요소의 목록을 작성해 올렸다. 빠진 API 중 일부는 커뮤니티 구현으로 전환되고 일부는 현대적인 대안으로 대체된다. 닷넷 프레임워크 코드를 지원하고 개발하는 이들에게 2020년은 미래에 코드가 전달되는 방법을 탐색할 좋은 기회가 된다. 현재의 닷넷 코어 3.1 릴리스는 장기 지원 버전이며, 닷넷 스탠다드 라이브러리와 함께 닷넷 5에 포함될 많은 API를 지원한다. 닷넷 코어 3.1로 코드를 이식하면 코드에서 무엇을 변경해야 하는지 탐색할 수 있을 뿐만 아니라 새로운 툴체인을 구축할 기회도 얻을 수 있다. 닷넷 코어의 미래는 ASP.NET과 레이저(Razor)를 통한 웹어셈블리(WebAseembly)와 서버 측 블레이저(Blazor), 윈도우, 맥OS, 리눅스의 닷넷 코어, 모바일 디바이스의 자마린(Xamarin)으로 구성되는 크로스 플랫폼이다. 코드를 닷넷 5로 전환하면 미래의 윈도우 릴리스를 지원할 수 있을 뿐만 아니라 훨씬 더 많은 플랫폼과 사용자에게 코드를 제공할 기회도 얻을 수 있다. WinUI 3.0 탐색 시작 2020년에는 윈도우 플랫폼에 변화...

리눅스 윈도우 도커 2020.01.03

'SQL, 자바, 파이썬...' 2020년 미국에서 인기 기술 10선

완벽한 IT 일자리를 찾아 안착하는 일은 쉬운 일이 아니다. 하지만 수요가 높은 분야에서 적절한 기술력을 갖추면 이직에 유리할 수 있다. 미국 취업전문 사이트 인디드(Indeed)는 2014년에서 2019년까지 구인 광고에 가장 많이 등장한 ‘기술력’을 분석해 2019년 기술 구인 시장을 주도했던 기술력이 무엇이며 2020년 어떤 기술력이 인기 있을지를 소개했다.    인디드의 경제학자 대니얼 컬버트슨은 “사람들이 새로운 일자리를 찾을 때 종종 원하는 일자리와 관련된 최첨단 기술을 설명하는 검색어를 사용한다”라며, "고용주 측에서는 이러한 능력을 갖춘 고도로 전문화된 기술 인력이 수요가 많다"라고 말했다.  인디드는 보고서에서 2014년 9월부터 2019년 9월까지 인디드닷컴(Indeed.com)에 게시된 구인공고를 쿼리하기 위해 500개가 넘는 기술 용어를 사용했다. 컬버트슨은 “2가지 이상의 직무를 요구하는 데 따른 영향을 조사하기 위해 기술력의 변화를 2가지 구성 요소로 쪼갰다. 하나는 직무 내 기술력 포화 상태(예 : 주어진 직무에 파이썬을 추가로 넣은 구인공기 게시물 수 증가)와 달라진 직무 혼합 상태(데이터 과학자같이 파이썬을 사용하는 직무에서 더 많은 기술력을 요구하는 구인공고 게시물 수)로 기술력의 변화를 나눴다. 모든 기술 직종의 데이터 과학자 비율이 현재의 1/3 정도였던 2014년 9월 수준에서 직무 혼합을 유지하는 것은 시간이 지남에 따라 '조정된' 파이썬 추세가 어떻게 진화했는지를 보여준다. 실제로 모든 기술력에 관해 이 과정을 반복했다”라고 설명했다.  이 연구에 따르면 2020년에는 파이썬, 데이터 과학 기술 및 일부 기존 기술을 포함한 특수 프로그래밍 언어가 IT전문가의 성공 티켓임이 밝혀졌다. 2020년에도 구인시장에서 인기 있을 10대 기술력과 이들이 지난 몇 년 동안 수요가 얼마나 달라졌는지를 알아보자.. 1. SQL 2019년 전체 구인공고 게시물에서 언급된 빈도 : 21.9% ...

리눅스 2020년 스크럼 2019.12.10

회사명:한국IDG 제호: ITWorld 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아00743 등록일자 : 2009년 01월 19일

발행인 : 박형미 편집인 : 박재곤 청소년보호책임자 : 한정규
사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2022 International Data Group. All rights reserved.