사용docker containers개발 대박!우리 uilicious 는 docker에서 우리의 모든 백엔드를 실행합니다.

It would have been impossible to have launch uilicious at our current cost and scale without docker.

그러나 모든 기술과 마찬가지로, 여러 호스트에서 Docker를 대규모로 실행할 때, 숨겨진, 뚜렷하지 않은 문제가 있다.특히 물리적 서버 또는 가상 시스템에서 마이그레이션되는 워크로드의 경우
명확하게 말하자면 본고는 시스템 최적화에 관한 것이 아니다.그러나 일반적인 오류 설정 설정에 관해서는 귀하와 귀하의 회사(YMV)가 파산할 수 있습니다.운영 시스템이 장시간 다운되거나 해커에게 데이터가 유출될 수도 있습니다.
본고는localhost에 대해 기본적인 docker 지식을 가지고 있다고 가정합니다.
따라서 다음은 제가 지난 4년 동안 불행하게도 Docker를 사용하여 살아남은 5가지 치명적인 문제와 각 점에 대한 빠른 요약입니다.어떻게 피할 것인가.

Note that when I refer to situations involving multiple hosts, this only applies for docker setups larger than a single host such as rancher 1.6 (which we use internally), Docker swarm, or Kubernetes, etc.

만약 이런 상황이 발생한다면 이미 너무 늦었을 것이다

1) Docker가 방화벽을 잘 사용하지 못함

Docker 호스트 포트 바인딩, 일반적인 iptables 입력 규칙 무시
유감스럽게도 많은 사람들이 본능적으로 Docker를 사용하여 용기 포트를 호스트에 연결하거나 전통적인 linux에서 일반적인 설정을 바꾸기 시작한다. (호스트에 있는 일반적인 IPtables 방화벽 규칙이 그것들을 검증하지 않은 상태에서 작동할 수 있다고 생각한다.)또는 많은 온라인 초보자 가이드라인을 따르는데, 이 가이드라인은 로컬 기기의 '호스트' 에 포트를 연결하여 개발을 편리하게 하는 경향이 있다. (이 문제에 대한 어떠한 건의도 없다.)
그러나Docker port binding uses iptables PREROUTING level by default.이것은 대부분의 IPtables 입력 방화벽 규칙보다 우선하며, 많은 사람들이 이러한 규칙을 사용하여 자신의 시스템을 보호한다.
결국 MySql 등 특권 포트를 인터넷에 공개했다.더 심각한 것은 Nosql 포트가 통상적으로 신분 검증 없이 배치되어 모든 개인 고객 데이터가 유출되어 해커에게 줄 선물로 사용된다는 것이다.
완화 지침

• Mitigate by using container to container communication
• Mitigate using network based rules
  • VPC/Firewall rules for AWS, Azure, DO or Google Cloud
  • On-premise router rules
  • Does not apply for Linode
• Alternative last resorts
  • Scrutinize, manaage and secure all host binded ports with authentication
  • Use custom docker iptables

다행히도 구글이나 AWS 등 공급자가 제공하는 가상 프라이빗 클라우드(VPC)에 네트워크 기반 방화벽 규칙을 적용함으로써 대부분의 상황을 쉽게 완화할 수 있다.또는 유사한 규칙을 적용해 서버를 안전하게 공개한다.
그러나 일부 클라우드 공급자에게 이 해결 방안은 하나의 옵션이 아니다. 가장 뚜렷한 것은 Linode이다. 그 중에서 개인 네트워크는 각자의 로컬 데이터 센터에서 모든 고객에게 공공 방문을 제공하는 것을 명확하게 가리킨다.
이런 상황에서 혹은;공개적으로 연결된 포트를 꼼꼼히 검사하고 복잡한 무작위로 생성된 비밀번호를 사용하여 적당한 보안을 확보할 수 있으며, 모든 비공식 통신은 용기와 용기의 네트워크 사이에서 발생하며, 심지어 양방향 SSL 인증까지 실현할 수 있습니다.또는 docker iptables 규칙을 만드는 상당히 복잡한 과정을 이해한다.
기타 세부 사항

Docker offical docs

Docker iptables guide

DigitalOcean deepdive into iptables

Docker and iptables

당신은 후원자가 있습니까?

2) docker 데이터의 지속성을 이해하지 못함

기본적으로 Docker는 컨테이너 데이터를 저장하지 않습니다!
우선, 이것은 매우 복잡한 화제이기 때문에, 나는 단지 그것을 간단하게 하고 싶다.
다음은 용기에서 데이터를 지속적으로 처리하는 방법을 소개하는 빠른 속성 과정이다.특히 용기를 다시 시작하거나 다른 호스트로 재배치할 때

1. Container, without volumes, store changes locally and temporarily. Data is destroyed if container is redeployed.
2. Default volumes, are persistent only on host, and does not transfer across host machines
3. On container shutdown, or health check failure, either of the following occurs.
   • Restart, container data, and volumes persist
   • Redeployed on the same host, volumes persist, container data is destroyed
   • Redeployed on a different host, no data persists !!!
     • This can occur in non-obvious ways such as host temporary failure
     • Infrastructure tool just decides to do so on a friday
     • Orphaned volume may get deleted by cleanup functions
4. Host storage can be mount directly as a volume, however...
   • this will be harder to monitor via docker
   • still suffer most of the same drawbacks to host volumes
   • atleast data does not disapear into a blackhole, and can be recovered using traditial SSH
   • in some critical cases this is preferred (we use this method for elasticsearch)
5. If auto rebuild onto other hosts is allowed, plan it extremely carefully.

그럼 이게 무슨 뜻이죠?다음은 실제로 발생한 고장 장면들입니다. 백업을 통해 보완했습니다.
볼륨이 있는 단일 컨테이너(호스트 제한 없음)

You have deployed a MySql container with a volume, on failure it restarted by default. One day as the host that is running mysql was disconnected from the docker cluster. Its cluster manager redeployed the container onto another host, attaching to a new volume.

Even worse there was a cleanup script for removing dangling volumes & containers. Making the data unrecoverable by the time you wake up.

호스트 제한 컨테이너, 볼륨 마운트 없음

You have designated a Jenkins container to deploy specifically on one host, and ensure its failure condition is to do nothing. This will mitigate the "rebuilt on a different host" scenario, yay!

However, on one sunny sunday, you notice that there is a security update required for Jenkins. You decided to click the upgrade button. Poof all your data is gone, as your container is being redeployed.

분산 Redundent 시스템, 호스트 제한 없음

You have deployed ElasticSearch on multiple hosts, with their respective volume container; Trusting that even if they were to fail individually, the magic inside ElasticSearch will rebalance and recover the data from its other replicas. One day you decided to do an upgrade, however you did not realise that you were running many more hosts in the cluster than the required containers.

During the upgrade, all the new version was deployed to previously unused hosts, and the old containers were terminated. Without having sufficient replicas, nor time to transfer the data over, as container start and stop actions are immediate.

All the data is lost. This can silently occur if you are using an autoscaling group.

완화 지침
상술한 상황을 완화하기 위해서는 다음과 같은 조치를 취해야 한다.

• Have backups, and learn how to restore them
• Ideally throw your persistent data outside your docker infrastructure
  • Use cloud managed SQL, or the various cloud managed Object / No-SQL services that are available
  • Or use the equivalent of google persistent disk / aws EBS directly in your docker container (if supported)
• Containers should as much as possible, hold zero data that requires persistency
  • Examples (zero persistency) : Frontend servers, Application servers
  • Counter-examples (requires persistency) : SQL servers, file servers
• For containers that hold persistent data
  • Be aware and cautious on what is the configured on healthchecks and its failure behaviour
  • Plan your upgrades carefully, upgrade one container at a time if needed
  • Healthcheck can be configured to "do-nothing" in response (perform manual intevention when needed)

기타 세부 사항

Docker 공식 문서here 및 here

Managing persistence for docker

npm/노드의 생명.js fastlane 좋아요...끝없는 의존의 바퀴가 헤어지기 시작할 때까지...

3) 사용: 컨테이너의 최신 레이블

관리되지 않은 자동 업그레이드는 시스템을 파괴할 수 있습니다.
흔히 볼 수 있는 모드는 사용 base container image 입니다. 자주 사용하는 용기 모듈을 합쳐서 확장해서 더욱 전면적인 용기 이미지를 얻을 수 있습니다.
또는 최신 공식 용기 이미지를 사용하여 배치할 수 있다. 예를 들어Jenkins 등이다.
그러나 서버가 고장나 자동으로 교체되면 최신 업그레이드 의존항은 집단의 다른 부분과 동기화되지 않을 수 있습니다.

In addition, there are times that the latest version makes backwards breaking change against your system that will result into major downtime. It only gets worse when certain systems can only be upgraded in one direction and will modify the shared files or resources in the process (eg: Jenkins, GitLab).

이런 상황은 버그를 추적할 때 복잡성을 초래할 수 있다.당신은 다른 기계가 아니라 한 기계에서만 이 문제를 만날 수 있습니다.변경을 진행하기 전에, 예를 들어 사용할 용기 템플릿의 최신 표시가 아니라 고정된 버전을 표시할 수 없습니다.
생산 환경에서, 당신은 속도를 늦추고, 고정 버전 제어를 사용하거나, 적어도 주요 버전/안정적인 지점을 사용하기를 원할 것입니다.그러나 테스트에 있어서 속도가 필요하다고 생각되면 최신 버전:latest을 자유롭게 선택할 수 있다.
포효에 대한 자세한 내용은 here를 참조하십시오.
완화 지침

• Just do not use :latest , adjust the rest according to your requirements
• Alternatively, only use your own container registry, and hand select all images deployed on it - this is the slow and painful way done in banks

그게 정확한 주소인지 잘 모르겠어요.

4) 컨테이너에 영구적인 IP 주소가 없음

컨테이너의 영구 IP 주소를 가정합니다.
IP 주소의 지속성을 가정하면 복잡한 문제가 발생할 수 있습니다. 보통nginx 부하 균형기에 있습니다.더 심각한 것은 설정 파일에서 IP 주소를 하드코딩하는 것이다.모든 용기가 '온라인' 으로 되어 있어 보기에는 좋으나, 그들 사이에는 통신이 없는 곤혹스러운 오류가 발생할 수 있다.

For example, if you are using Nginx as a load balancer to multiple containers, the IP addresses of domain names are resolved on startup by default. This means that if any of the containers' IP addresses that the Nginx load balancer is connected to is modified, the load balancing will not update and fail. (unless you are using Nginx Pro)

완화 지침

• kubernetes : learn to use cluster IP, its a game changer against this problem.
• Configure your stack to use hostnames over fixed ip addresses
  • This assumes the application supports dynamic ip on hostnames
  • Use alternatives to Nginx like HAProxy, or Traefik for load balancing,
  • If not possible, use health checks to automate contatainer restarts to fix hostname routing

기타 세부 사항

Docker documentation

Nginx documentation - on lack of dynamic ip support

새로운 초현과학기술의 출현은 모든 사람들이 ABC를 다시 배워야 할 것 같다

5) CPU, RAM 및 디스크 부족 - 계획 및 모니터링

Docker는 단지 추상층일 뿐, 기본 원리는 변하지 않는다
대부분의 클라우드 공급자에서는 기본적으로 랜덤 액세스 메모리 (RAM) 와 디스크 메모리 사용 상황을 실례 계기판에 표시하지 않기 때문에 더욱 화가 난다.
만약 계획을 잘못하면 한 대의 호스트 고장으로 인해 자원 부족 오류의 연쇄 반응을 초래하여 집단이 영향을 받은 용기를 다른 호스트로 다시 포지셔닝하게 할 수 있다.이것은 반대로 더욱 많은 자원 부족 오류를 야기할 것이다.

A common example of this occurrence is during the deployment of multiple containers such as SQL, NoSql or file servers. Which by default would simply attempt to consume as much ram as possible for performance, as usage increases.

또 다른 자주 잊혀지는 일: 엔트로피와 대수 회전
만약 그렇지 않다면, 만약 인증 시스템이나 SSL을 사용한다면, 엔트로피는 어느 때 일을 멈출 때까지 늦출 것입니다.또는 로그 교체는 서버가 로그로 인해 파일 공간을 소모하지 않도록 하는 데 도움이 된다.
마지막으로 백업, 백업 및 백업이 있습니다.

좋은 계기판은 어느 정도 시스템의 운행을 유지할 수 있다
완화 지침

• Plan your RAM and disk usage requirements properly, keeping in mind to having additional buffer space if case of any overheads that may occur.
• Place limits on RAM for individual containers.
  • Use this to limit damage for "out of control" errors, from a container, to others on the same host.
• Monitor your usage requirements either via dashboards, or manually every now and then
  • Elasticsearch your metrics (free, but troublesome to setup)
  • Datadog your metrics (not-free, but many things are out of the box inbuilt)
• Clean up dangling containers / images / volumes, which will free up unused space.
• Deploy server essentials (according to your requirements)
  • Entropy Generation (especially for cloud servers) - container
  • Log rotation - container

(만일의 경우): 클러스터를 영구 장애 상태에서 복구

Note that when such cascading "out-of-resource" error occurs, the safest solution is to

• Stop / shutdown the whole cluster
• Stop all scheduled containers
• Reactive containers group by group

In this manner, the cluster does not get overwhelmed at any given point in time.

그리고 하나 더: 모니터링은 http 코드 200에 관한 것이 아니다

모니터링도 기능에 적용된다.정적 파일 서버가 성공적으로 시작되고 실행될 수도 있습니다.손상된 JS 파일은 모든 브라우저 기능을 자동으로 중단합니다.
api에 내장된 복잡한 헬스 체크 명령이나 정적 사이트의 텍스트 기반 건강 검사를 통해 이를 실현할 수 있습니다.
uilicious를 사용하여 업무 모니터링을 간단하게 할 수 있습니다.당신은 간단한 테스트 용례를 신속하게 구축하여 사이트에 대해 완전한 끝에서 끝까지 테스트를 하고 백엔드에서 테스트 운행을 배정할 수 있습니다.만약 테스트 용례가 실패한다면, 우리는 자동으로 당신에게 통지할 것입니다.

// Test scripts can be as simple as the following
I.goTo('https://google.com')
I.fill("Search", "uilicious")
I.pressEnter()
I.click("Smart User Journey Testing")
I.amAt("https://uilicious.com")

You can give the above test snippet a try on our public test platform (no login required)

or signup for a free trial .

결말

이상의 내용이 고통스러운 경험을 피하는 데 도움을 줄 수 있기를 바랍니다.그러나 모든 급속히 발전하는 신기술처럼 모든 것은 신중해야 한다.(부언: 2018년 11월에 업데이트되었습니다)

Docker 장면과 도구가 빠르게 변화하고 있습니다. 계속 공부하고 읽으세요.

신기한 것은 없다. 모두 도구다. 그것을 배워라.

기본값, 튜토리얼 가이드를 맹신하지 말고 그 기능을 배워라.

시스템이 가능한 여러 가지 상황에서 어떻게 실패할지 파악하고 이를 중심으로 계획을 세웁니다.

가장 중요한 것은 테스트 환경을 갖추고 그곳에서 실험을 하는 것이다. 이 과정에서 안전하게 실패할 수 있다.

쾌락항운🖖🏼🚀