• Faster Builds with Container-Based Infrastructure and Docker

  • 도커와 컨테이너 기반 인프라스트럭처를 통한 더 빠른 빌드

  • Stability and reliability in your builds is the one thing we aimed to give since Travis CI came about. But we haven't always been able to live up to this expectation. Network issues, insufficient build capacity (for open source projects) which in turn lead to long wait times for your build to start, constrained CPU and memory resources in the builds environment, lack of caching for open source projects. As most our current Linux stack runs on a private cloud, we've also had issues adding capacity, as we had to go through the process of ordering and waiting for more capacity.
  • 안정적이고 신뢰성있는 빌드를 제공하는 것이 Travis CI 의 목표입니다. 하지만 그동안 기대에 부응하지 못한 것이 사실입니다. 네트워크 문제, 빌드 자원 부족(오픈소스 프로젝트에 대해)으로 인한 느린 빌드 시작, 제한된 CPU와 메모리 자원, 오픈소스 프로젝트에 대한 캐싱도 없던 것이 현실입니다. 현재 대부분의 리눅스 시스템이 비공개(private) 클라우드에서 동작하고 있기 때문에, 처리량을 늘리는데도 어려움을 겪어 왔고, as we had to go through the process of ordering and waiting for more capacity.
  • Today we're happy to announce our new build infrastructure, which addresses some of these issues. It's available for private and open source repositories as of today!
  • 드디어 오늘, 이러한 이슈들을 해결하기 위한 새로운 빌드 인프라스트럭처를 소개할 수 있게 되어 매우 기쁩니다.
    비공개 소스와 오픈소스 리포지터리 모두 오늘부터 사용 가능합니다!
  • What benefits does this new infrastructure have?

  • 새 인프라스트럭처를 통한 이점은 무엇인가?

  • Builds start in seconds
  • 바로 시작하는 빌드
  • Rather than wait for builds to start for a long time, your builds now start in less than 10 seconds. Assuming that capacity is available (which is now a lot easier for us to scale), you'll see your builds going from being scheduled to starting in only a few seconds.
  • 빌드가 시작되기까지 오랜 시간이 걸렸는데, 이제는 10초 내외로 시작할 수 있습니다.
    수용 가능한 상태라면(이제 확장하기가 훨씬 쉬워지기도 했고), 예약된 빌드가 몇 초만에 실행되는 것을 볼 수 있습니다.
  • Faster builds
  • 보다 빠른 빌드
  • We've been helping projects move over to this new stack, and we've seen much better build times for most of them. The mileage may still vary based on how heavy your builds are on I/O, but most projects should see an improvement. We'd love to hear from your if you don't or if you see slower build times.
  • 새 시스템으로 프로젝트를 이전하는 것을 지원하다 보니, 대부분 빌드 시간이 매우 단축됨을 알 수 있었습니다. 이득은 빌드가 얼마나 I/O를 많이 사용하느냐에 달려있긴 하지만, 대부분의 프로젝트에서 향상된 속도를 경험할 수 있습니다. 빌드 시간이 단축되거나 혹은 느려진 것에 대한 얘기를 듣고 싶습니다.
  • More available resources in a build container
  • 빌드 컨테이너에 더 많은 자원 할당
  • The build containers in our legacy build infrastructure has had 1.5 cores (with burst capacity) and 3GB of memory. The CPU resources are now guaranteed, which means less impact by noisy neighbors on the same host machine. Build times throughout the day should be much more consistent on the new container stack.
  • 예전 빌드 시스템의 컨테이너는 1.5개의 코어(with burst capacity) 와 3GB 의 메모리를 가지고 있었습니다. 이제 CPU 자원은 보장되었으며, 이는 같은 호스트 장비의 다른 빌드에게 영향을 덜 받게 됨을 의미합니다. 예전보다 빌드 시간에 일관성을 보장할 수 있게 되었습니다.
  • The new containers have 2 dedicated cores available and 4 GB of memory.
  • 새로운 컨테이너는 독립된(dedicated) 2개의 코어와 4GB 의 메모리를 가집니다.
  • Better network capacity, availability and throughput
  • 네트워크 가용성과 성능 향상
  • Our new stack is running on EC2, which means much faster network access to most services, especially those hosted on EC2 as well. Access to S3 is now also a ton faster than on our legacy stack.
  • 우리의 새로운 시스템은 EC2 위에서 동작하므로, 대부분의 서비스에 - EC2위에서 동작하는 경우에 특별히 - 더 빠른 네트워크 접근이 가능해졌습니다. S3로의 접근도 예전에 비하면 격세지감일 정도로 빨라졌습니다.
  • Caching available for open source projects
  • 오픈소스 프로젝트를 캐시할 수 있게 됨
  • The best news for open source projects is that our build caching is now available for them too. That means faster build speeds by caching dependencies. Make sure to read the docs before trying it out.
  • 오픈소스 프로젝트들에 가장 좋은 소식은 빌드 캐싱이 가능해졌다는 점입니다. 캐싱 여부에 따라 더 빠른 빌드가 가능해졌음을 의미하죠. 시도하기 전에 반드시 도움말을 읽어보시길 바랍니다.
  • For Ruby projects, it's as simple as adding cache: bundler to your their .travis.yml.
  • 루비 프로젝트의 경우 .travis.yml에 cache: bundle를 추가하는 것으로 간단히 가능합니다.
  • Easier to scale
  • 확장에 용이
  • This might not be a direct benefit to our users and customers, but it is one for us. We can now respond to demand much quicker and increase our build capacity in mere minutes. That allows us to ensure that open source projects are less likely to hit capacity peaks and wait in line for too long until they run.
  • 이 점은 사용자가 고객보다는 우리에게 이득이 되는 부분입니다. 이제는 필요한 때에 수 분 이내로 빌드 가용량을 빠르게 늘릴 수 있게 되었습니다. 이를 통해 오픈소스 프로젝트들을 빌드하다 가용량의 한계에 다다르지 않고, 작업을 시작할 때까지 너무 오래 기다리지 않도록 할 수 있게 되었습니다.
  • How can I use it?

  • 어떻게 쓸 수 있나?

  • Using our new container-based stack only requires one additional line in your .travis.yml:
  • 사용하고 있는 .travis.yml 파일에 한 줄만 넣어 새 컨테이너 기반 시스템을 사용할 수 있습니다.
  • sudo: false
  • sudo: false
  • What are the restrictions?

  • 어떤 제약이 있는가?

  • Using sudo isn't possible (right now)
  • sudo 를 사용할 수 없음 (현재까지는)
  • Our new container stack uses Docker under the hood. This has a lot of benefits like fast boot times and better utilization of available machine resources. But it also comes with restrictions imposed by security.
  • 우리의 새로운 컨테이너 스택은 도커를 사용하고 있습니다. 덕분에 빠른 부팅 시간과 효율적인 기기 자원 활용이 가능해졌습니다. 하지만 보안과 관련된 몇 가지 제약사항이 생겼습니다.
  • At this point, it's not possible to use any command requiring sudo in your builds.
  • 아직까지는 빌드 과정에서 sudo 를 요구하는 작업을 할 수 없습니다.
  • If you require sudo, for instance to install Ubuntu packages, a workaround is to use precompiled binaries, uploading them to S3 and downloading them as part of your build, installing them into a non-root directory.
  • 우분투 패키지를 설치하는 것과 같은 sudo 가 요구되는 작업에는, 미리 컴파일된 바이너리를 S3 에 올려 빌드 과정에 다운로드 받아 root 가 아닌 디렉토리에 설치하도록 해야 합니다.
  • Databases don't run off a memory disk
  • 데이터베이스는 메모리 디스크 상에서만 구동되야 함
  • On our legacy and legacy legacy stack, both MySQL and PostgreSQL ran off a memory disk to greatly increase transaction and query speed. This can impact projects depending on their use of transaction, fixtures and general database usage, but the impact generally shouldn't be negative.
  • 우리의 예전, 그리고 예~전 방식에서는 MySQL 과 PostgreSQL 모두 트랜잭션 증가와 쿼리 속도를 위해 메모리 디스크를 벗어나곤 했습니다. 이는 프로젝트의 트랜잭션 사용과 기본 데이터(fixtures)나 일반적인 데이터베이스 사용에 따라 다른 영향을 주겠지만, 일반적으로 부정적이진 않을 것입니다.
  • Tell me about this new stack?

  • 새 구조에 대한 보다 자세한 설명

  • Over the past year, we've been working on Travis CI Enterprise, our on-premises solution for GitHub Enterprise customers. Part of working on this stack required us to think about how to best run on custom infrastructure like internal OpenStack, VMware and other virtualization setups, and even on bare metal hardware.
  • 지난 수 년간, Github Enterprise 고객을 대상으로 하는 설치형 Travis CI Enterprise 를 작업해 왔습니다. 이러한 작업은 OpenStack, VMware 와 같은 가상화 환경 뿐 아니라 물리 하드웨어를 포함하는 다양한 환경 하에서 가장 좋은 방법은 어떤 것인가 생각하게끔 했습니다. (역주: 부정확한 번역입니다)
  • Our legacy stack runs on a proprietary, managed cloud with APIs not available in our customers' datacenters. Both for packaging our entire stack for installation, but also for running builds in isolated environments, we started looking at Docker as an alternative about a year ago.
  • 이전 시스템은 고객의 데이터센터에는 없는 독점적으로 관리되는 클라우드 API 상에서 동작했습니다. 우리 전체 시스템의 설치를 패키지화 하는 것과 더불어 격리된 빌드 환경을 운영하는 일을 위해 작년부터 도커를 대안으로 보고 있었습니다.
  • Our new stack can run on pretty much anything we or our customers would like it too. That allows for custom Travis CI Enterprise installations on EC2, Digital Ocean, Linode, Rackspace, or fully in-house infrastructure.
  • 우리의 새로운 시스템은 우리 뿐 아니라 고객들이 원하는 대부분의 환경 하에서 실행될 수 있습니다. 사용자에 맞춰진 Travis CI Enterprise는 EC2, Digital Ocean, Linode, Rackspace 뿐 아니라 완전한 인하우스 인프라스트럭처에도 설치 가능합니다.
  • We've verified a few options upfront, but EC2 turned out to have the better performance and more reliable network.
  • 몇 가지 안을 테스트해보았는데, EC2 가 좋은 성능과 신뢰성 높은 네트워크를 가진 것으로 확인되었습니다.
  • Our new stack for hosted private and open source projects is running on EC2 inside of Docker containers. We've seen great performance both in the network and with compute resources, and the direct access to S3 makes build caching a lot faster.
  • 비공개 및 오픈 소스 프로젝트를 위한 우리의 새로운 시스템은 EC2 상의 도커 컨테이너에서 동작합니다. 네트워크과 연산 자원 모두에서 대단한 성능을 확인하였으며, S3에 바로 접근할 수 있어 캐시를 생성하는 것도 빨라졌습니다.
  • I have more questions...

  • 그래도 몇 가지 궁금한게 있는데...

  • Can I provide my own Docker containers?
  • 원래 쓰고 있던 (독자적인) 도커 컨테이너를 사용할 수 있는가?
  • The build environments we're currently using on our Docker-based setup provide the same services, programming languages and tools offered by our legacy stack. We've been keeping them on par as much as possible.
  • 현재 운영중인 도커 기반 빌드 환경은 예전 시스템과 동일한 서비스, 프로그래밍 언어와 도구를 제공합니다. 이를 최대한 장기간 유지하려고 합니다.
  • The lack of sudo does make it hard to install custom libraries and services, running them on privileged ports, or simply using apt. The question for providing your own images is a natural one.
  • sudo를 사용할 수 없어 사용자 라이브러리나 서비스를 설치하기도 어렵고 특정 포트에서 실행하거나 단순히 apt 를 쓰는 것도 어렵습니다. 그러하기에 사용자 이미지에 대한 질문은 매우 당연한 것으로 여겨집니다.
  • We're not there yet in allowing you to bring your own, but it's something we have in mind for the future.
  • 아직까지는 사용자 이미지를 허용하고 있지는 않지만, 앞으로 염두에 두고 있는 일입니다.
  • Can I build Docker containers as part of my build?
  • 빌드 과정에서 일부만 도커 컨테이너에서 수행 가능한가?
  • Same as the above. It's not currently possible, mostly for security reasons, but is something we want to address in the future.
  • 위와 같습니다. 현재는 대부분은 보안상의 이유로 불가능하지만, 앞으로 다뤄볼 문제입니다.
  • Can I run Docker inside Docker?
  • 도커 안에서 도커를 실행할 수 있는가?
  • Running Docker containers as part of your build currently isn't possible because of questions related to security due to the underlying container technology. We have things planned to address this in the future.
  • 컨테이너 기술의 보안 문제로 빌드 과정에서 도커를 실행하는 일은 현재로서는 불가능합니다. 언젠가는 이 문제를 해결할 것입니다.
  • Containers everywhere

  • 컨테이너가 지배하는 세상

  • This is only the beginning of offering a better, faster and more reliable builds on Travis CI. We have a lot more things planned to improve stability, but we're excited to ship this today.
  • 이는 Travis CI 에서 더 나은, 빠르고 신뢰성 높은 빌드를 만들어 나가는 것의 시작에 불과합니다. 안정성 개선과 관련된 많은 것들이 준비되어 있지만, 일단 오늘 출시하는 것만으로도 매우 기쁩니다.
  • Give it a spin and let us know what you think!
  • 한 번 굴려보시고 어떤지 좀 알려주세요!
0 Comments