항상 사용중인 사이트에서 유지 관리를 실행하는 방법에 대한 아이디어가 있습니까?

호주의 대형 게임 사이트를 도와드립니다. 우리는 매일 오전 7 시부 터 다음 날 오전 1 시까 지 시합을 운영합니다. 사이트가 릴리스 된 이후 하루를 건너 뛰지 않았습니다. 당연히 이로 인해 유지 관리가 매우 어려워지고 스테이징 서버가 프로덕션 브랜치보다 최대 50 개 커밋됩니다. 일반적으로 주요 개발자는 지점을 병합하고 모든 것이 제대로 작동하는지 확인하기 위해 매우 일찍 일어나야합니다.

준비 사이트를 프로덕션 사이트와 최대한 비슷하게 만들려고 노력했지만 비슷한 사이트 만 만들 수 있습니다.

저희 사이트는 Laravel을 기반으로 Node.JS 서버를 실시간으로 제공합니다. 우리는 Laravel Forge를 사용하고 있습니다.

누구든지 업데이트를 더 자주 푸시 할 수있는 방법에 대한 제안이 있습니까? 우리는 무엇이든 열려 있습니다.

배포 프로세스를 개선하기 위해 수행 할 수있는 작업이 많이 있습니다. 그들 중 몇 가지는 :

• 코드가 제대로 테스트되었는지 확인하십시오.

  이상적으로 100 % 단위 테스트 범위와 모든 가능한 시나리오에 대한 통합 테스트가 있어야합니다.

  이것을 얻지 못했다면 아마도 모든 것을 버리고 이것을 처리해야합니다.

  행동 중심 개발을 살펴보십시오.

  완벽한 테스트 스위트를 갖추면 다음을 수행 할 수 있습니다.

• 지속적인 통합을 실행하십시오.

  누군가 변경 사항을 커밋 할 때마다 CI는 테스트 스위트 를 자동으로 실행할 수 있습니다 . 테스트 스위트가 통과하면 즉시 배포하거나 배포를 예약 할 수 있습니다. 데이터베이스를 크게 변경할 필요가없는 변경의 경우, 이것만으로 많은 시간과 두통을 줄일 수 있습니다.

  문제가 발생하면 CI는 원 클릭 롤백을 제공 할 수도 있습니다.

  전체 전제는 자동화 된 방식으로 코드를 검증 할 수 있기 때문에 테스트 스위트가 완전하고 정확하지 않은 경우 CI는 그다지 유용하지 않습니다.

• 원자 업데이트를 수행하십시오.

  이상적으로 프로덕션 서버에서 이전 파일을 통해 새 파일을 복사하지 않아야합니다. 대신, 모든 파일을 새 위치로 복사 한 다음 기호 링크를 사용하여 원하는 배치를 가리키는 capistrano와 같은 도구를 사용하십시오. 롤백은 단순히 이전 배포를 가리 키도록 심볼릭 링크를 변경하는 것과 관련이 있기 때문에 즉각적입니다. (이것이 반드시 데이터베이스 마이그레이션을 다루지는 않습니다.)

  Docker와 같은 컨테이너가 도움이 될 수 있는지 여부도 살펴보십시오.

• 더 작고 더 자주 변경하십시오.

  테스트, CI 또는 아무것도 없는지 여부에 관계없이 이것만으로도 크게 도움이 될 수 있습니다. 모든 변경 사항에는 자체 git 브랜치가 있어야하며 배포에는 가능한 한 적은 변경 사항이 있어야합니다. 변경 사항이 더 작으므로 배포 중에 잘못 될 가능성이 줄어 듭니다.

  이 메모에서 가능할 때마다 변경 내용을보다 격리시킵니다. Omaha 게임을 변경했는데 Texas Hold'em, 5 카드 스터드 또는 다른 것에 영향을 미치지 않으면 유지 관리를 위해 일시 ​​중단 해야하는 유일한 게임입니다.

• 오래 실행되는 모든 것을 분석하십시오.

  배포 중 일부에 시간이 오래 걸린다고 언급했습니다. 이다 아마 데이터베이스 스키마 변경. DBA가 각 스키마 변경과 함께 데이터베이스를 살펴보고 성능이 더 좋은 것을 확인하는 것이 좋습니다.

  주제 전문가에게 배치의 다른 부분을 살펴보면 시간이 많이 걸립니다.

• 이상한 시간을 보내십시오.

  이미이 작업을 수행하고있을 수도 있지만 언급하고 있습니다. 개발자 (및 sysadmins!)는 특히 24x7 작업을 위해 더 이상 "9-5"로 작동하지 않아야합니다. 누군가가 배치를 보모하고 문제를 해결 한 다음 주간 일정을 유지하는 데 밤새 시간을 소비 할 것으로 예상되는 경우, 귀하의 기대는 비현실적이며 해당 사람을 소진하도록 설정하고 있습니다.

매일 오전 1시에서 오전 7시 사이에 유지 관리 기간이 있다고 말하는 것처럼 문제는 시간이 아니라 편의입니다. 이것은 정상이며 많은 사람들이 비즈니스의 일부로 처리합니다.

프런트 엔드가있는 2 개 이상의 백엔드 시스템을 사용하여 트래픽을 현재 존재하는 모든 사람에게 전달할 수 있습니다. 릴리스가 제대로 작동하면 프론트 엔드에 새 시스템으로 전환하도록 지시하십시오. 이것은 짧은 시간 내에 스크립트를 작성하기 쉬워야합니다.

이제 기존 시스템을 그대로두고 다시 업데이트하거나 최신 상태로 유지할 수 있으므로 다음 업데이트를 빌드 / 테스트 할 때까지 라이브 시스템의 예비 시스템으로 사용할 수 있습니다.

다른 답변 수정 : 청록색 배포 모델을 따라야합니다 . 새 버전을 출시하려면 내부 준비 웹 사이트에 배포하십시오. 그런 다음 다음 버전 프로덕션 사이트에서 자동 테스트를 실행할 수 있습니다. 테스트가 진행되면로드 밸런서가 새 웹 사이트를 사용하도록 지시합니다.

이것은 다음과 같은 방식으로 도움이됩니다.

1. 다운 타임이 전혀없는 심각한 문제는 항상 발견됩니다.
2. 새 버전으로 전환하면 다운 타임이 없습니다. 새 버전이 이미 시작되어 예열되어 있기 때문입니다.
3. 여전히 물리적으로 실행 중이므로 언제든지 이전 버전으로 다시 전환 할 수 있습니다.

언제든지 스트레스없이 배포 할 수 있으면 나와 다른 사람들이 언급 한 다른 모든 문제가 덜 심각해집니다. 청록색 배포 모델은 배포 문제에 대한 완벽한 솔루션입니다.

주 데이터 센터에 정전이 발생하면 어떻게됩니까? 때때로 모든 데이터 센터에서 발생합니까? 가동 중지 시간을 수락하거나 다른 데이터 센터로 장애 조치하거나 여러 데이터 센터에서 항상 활성-활성 모드로 실행 중이거나 다른 계획이있을 수 있습니다. 둘 중 어느 것이 든 릴리스를 수행 할 때 수행 한 다음 릴리스 중에 기본 데이터 센터를 중단시킬 수 있습니다. 데이터 센터에 정전이 발생했을 때 가동 중지 시간이 발생하면 가동 중지 시간이 발생하므로 릴리스 중에는 문제가되지 않습니다.

이전 답변에 추가하려면

• 롤백 및 즉시 전환, Capistrano 또는 거의 모든 다른 배치 시스템이이를 지원하는 배치 전략을 사용하십시오. 데이터베이스 스냅 샷 및 코드 심볼릭 링크와 같은 것을 사용하여 이전 상태로 빠르게 되돌릴 수 있습니다.

• 완전한 구성 관리를 사용하고 수동으로 관리되는 것은 두지 마십시오. SaltStack, Ansible 및 Puppet과 같은 시스템이 그 예입니다. Docker 컨테이너 구성 및 방랑 상자에도 적용 할 수 있습니다.

• HA를 사용하여 노드를 업그레이드 할 때 요청을 전달할 수 있는지 확인하십시오. 업그레이드가 실패하면 간단히 노드를 다운하고 롤백 할 때 다시 가져 오면 HA 솔루션이 해당 노드로 요청을 통지하고 다시 푸시합니다. HAProxy가 예제이지만 nginx도 잘 작동합니다.

• 애플리케이션이 캐시와 같이 디스크에 저장해야하는 비 코드 데이터에 대해 중앙 버전 데이터 저장소를 사용하여 동시 인스턴스를 처리 할 수 ​​있는지 확인하십시오. 이렇게하면 다른 버전의 파일을 캐시하기 위해 업그레이드 된 응용 프로그램을 실행할 수 없습니다. 이것은 캐시를 제거하고 캐시 예열을 수행하는 것 위에서 수행됩니다. (캐싱은 단지 예일뿐입니다)

나는 일반적으로 팀 관리자가 모든 일반 CI 작업을 수행하는 특수 브랜치에 대한 병합 요청을 승인 할 수있는 워크 플로를 설정했지만 추가 마지막 단계로 생산 노드로의 전환을 시작합니다. 기본적으로하는 일은 프로덕션 인스턴스에 수동 CI 배포를 실행하는 것입니다. 해당 인스턴스가 유효하지 않은 응답을 생성하지 않거나 데이터에 이상한 일을하는 경우 선택한 CI 솔루션을 사용하여 모든 노드를 대량 업그레이드합니다. 이렇게하면 한 배포가 작동하면 모든 배포가 특정 태그 / 커밋에 대해 작동한다는 것을 알 수 있습니다.

지금은 하나의 배포 프로세스, 하나의 소스 및 하나의 대상으로 단일 노드에서 프로덕션 애플리케이션을 실행하는 것처럼 들립니다. 이는 실제로 해당 워크 플로의 모든 단일 단계가 자체적으로 웹 사이트를 손상시킬 수있는 실패 지점임을 의미합니다. 이러한 일이 발생하지 않도록 보장하는 것은 모든 CI, HA 및 장애 조치 프로세스의 기본입니다. 하나의 노드 만 실행하지 말고 하나의 HA 프로세스 만 실행하지 말고 하나의 IP 주소 만 실행하지 말고 하나의 CDN 만 실행하지 마십시오. 비용이 많이 들지만 이미 가지고있는 것의 복제본을 두는 것 자체 연결이있는 서버의 랙에있는 경우 일반적으로 비즈니스 사이트에서 다운 타임이 1 시간 미만입니다.

나는 그의 모든 요점 ( /server//a/739449/309477 ) 에서 Michael과 전 세계적으로 동의합니다 .

제 생각에 가장 먼저 개선해야 할 것은 배포 도구 (Capistrano)를 사용하는 것입니다.

이를 통해 평화롭게 배포 한 다음 최신 버전으로 즉시 전환 할 수 있습니다. 문제가 발생하면 현재 심볼릭 링크를 작업 버전으로 변경하여 작업 버전으로 즉시 전환 할 수 있습니다.

Capistrano는 첫 번째 처리 속도가 매우 빠릅니다 (테스트 및 CI 사용을 시작하는 데 비해 시간이 오래 걸릴 것임)

둘째, 돈이 주된 문제 가 아닌 경우 프로덕션에 배포하기 전에 앱을 테스트 할 아이소 프로드 개발 서버가 있어야합니다. 사용 산업 VPS 인스턴스를 관리하는 솔루션 (Ansible, 요리사, 꼭두각시).