공통 데이터베이스를 가리키는 여러로드 밸런스 서버가있는 상황이 있습니다.
정상적인 작업에서 이것은 잘 작동하며 중복성, 확장 성 등을 제공합니다.
그러나 우리는 배치가 약간 번거로운 일이라는 것을 알았습니다.
우리는 기능을 광범위하게 사용하고 있으며 배포를 자동화하려고합니다. 현재 배포는 매우 안정적이지 않습니다.
단순화 된 형태로 각 서버의 배치 스크립트에는 두 단계가 있습니다.
파일 업데이트
기능 되돌리기 (종속성, 설정 변경 등을 관리함)
일관성이없는 상태로 여러 서버에 배포하는 모범 사례가 있습니까?
1 단계와 2 단계를 서버 A에 배치하면 서버 B가 중단 될 수 있습니다. 2 단계로 진행하기 전에 두 서버 모두에서 1 단계를 시도하면 둘 다 잠시 중단됩니다.
답변:
아마도 가장 유연하고 강력한 Drupal 사이트 관리 / 배포 시스템 인 Aegir을 살펴보아야 할 것입니다 . 다양한 웹 구성뿐만 아니라 여러 웹 헤드에 걸쳐있는 '플랫폼'을 관리 할 수 있습니다.
나는 그들의의를 통해 읽은 게 좋을 것 커뮤니티 문서 일반적으로 아주 좋은입니다뿐만 아니라 통해 읽기 mig5의 훌륭한 개요 및 소개 글 과 같은 그의 다른 기사 몇몇 이 하나 .
#aegir IRC 채널에서도 훌륭한 지원을받을 수 있습니다.
약간의 워크 플로우 변경이 될 것이므로 머리를 가져 오는 데 시간이 다소 걸릴 수 있지만 일단 방문하면 되돌아 보지 않을 것입니다.
우리 회사에서는 많은 Drupal 사이트를 관리하고 있습니다. 현재 설정은 다음과 같습니다.
위의 내용은 대부분의 Drupal 사이트에서 일반적입니다.
우리 회사에서 특별하게하는 것은 사용자 정의 drush 명령 인 ' Drush Debian Packaging '을 사용하여 배포 할 사이트를 데비안 패키지하는 것 입니다.
Drush Debian Packaging은 Drupal 사이트를 Debian 또는 Ubuntu 서버에 배포하는 수단으로 Drupal 사이트의 Debian 패키지를 빌드하기위한 Drush 명령을 제공합니다.
Drush Debian Packaging은 Drupal 후크 시스템을 사용하여 사이트 요구에 가장 적합한 Debian 패키지를 구축합니다. 특징은 다음과 같습니다.
이것은 무엇을 의미 하는가?
릴리스를 빌드하려면 다음을 수행하십시오.
cd /path/to/drupal-root
drush dh-make릴리스를 배포하려면 먼저 클러스터의 모든 웹 서버에 .deb를 SCP로 만듭니다. 그런 다음 모든 웹 서버에서 실행하십시오 (linux 패키지 cssh 를 사용 하여 동시에 팜의 모든 서버에 명령을 입력 할 수 있습니다 ).
sudo dpkg -i drupal-site-yoursitehere.2011.05.25-1.all.deb하나의 웹 서버에서 다음을 실행하십시오.
cd /path/to/drupal-root
sudo -u drupal-site-yoursitehere drush updb && drush fra -y && drush cron끝난
물론 롤백하는 것은 이제 코드베이스 관점에서 사소한 것입니다. 모든 웹 서버에 이전 버전의 .deb를 설치하고 데이터베이스를 롤백하면됩니다.
이것에 대한 질문에 답변 해 드리겠습니다
배포 프로세스의 어느 부분이 번거 롭거나 신뢰할 수 없습니까?
"업데이트 서버 A와 B / 비 일관성"문제인 경우 푸시 기간 동안 유지 보수 페이지를 올리는 것은 어떻습니까? 유지 관리 페이지 업, 두 웹 헤드의 코드 업데이트, 그 중 하나 에서 update.php를 실행 , 유지 관리 페이지 다운 꽤 쉽게 스크립트 할 수 있습니다.
다른 옵션 : 실행하는 사이트의 종류에 따라 모든 사용자를 오프라인으로 시작하고 로그인 / 등록을 비활성화하는 "읽기 전용 모드"를 만들 수 있습니다. DB를 동일한 db 상자의 두 번째 DB에 복제하고, 프론트 엔드를 새 docroot에 복제하고, 업데이트를 수행 한 다음 Apache의 docroot를 새 프론트 엔드 docroot에 symlink하십시오. 워크 플로우는 다음과 같습니다.
Entendu가 제안한대로 변경 사항에 따라 다릅니다. 데이터베이스가 아직 업데이트되지 않은 경우 오류를 발생시키지 않고 실행할 수있는 코드 업데이트 비율은 무엇입니까? 데이터베이스 업데이트에 의존하지 않는 (그리고 개발 프로세스를 좀 더 일반적으로 만들기 위해 약간 변경 할 수있는) 것은 특별한 일이 없습니다. 가동 중지 시간을 최소화하면서 배포를 원한다고 가정합니다. 그렇지 않으면 몇 가지 기본 동기화 작업이 필요합니다. 이 경우 원치 않는 효과가있는 시간이 항상 있습니다 (단지 사이트가 읽기 전용 모드 인 경우에도). 그러나 대부분의 시간이 상당히 작을 수 있다고 생각합니다.
각 서버에서 "새"디렉토리를 미리 설정 한 다음 동시에 새 디렉토리를 가리 키도록 전환 (Entendu의 답변과 같은 심볼릭 링크 사용)과 같은 기본 최적화를 수행하여 모든 서버는 5-10 초 내에 새 파일로 전환했습니다.
데이터베이스 업데이트 문제가 남아 있습니다. 서버 한 대에서만 수행해야하는 서버 인 경우 다른 서버를 유지 관리 모드로 설정하거나로드 밸런서를 조정하여 이러한 서버가 사용되지 않도록 할 수 있습니다. 물론 사용자가 사이트에서 활동하는 동안 수행 할 수없는 경우 유지 관리 모드로 모든 것을 유지해야하지만 간단한 업데이트의 경우 약 30 초 이내에 수행 할 수 있습니다.
다른 유형의 변경 사항에 대해 다른 배포 스크립트를 사용하는 것이 좋습니다. 따라서 파일을 복사하거나 작은 데이터베이스 업데이트를 실행하거나 주요 데이터베이스를 변경하는 등 필요한 최소한의 프로세스를 실행할 수 있습니다.
파일 및 데이터베이스 업데이트를 최적화하고 개발 방식에 대한 간단한 변경 사항이 있는지 살펴보면 더 가까이 갈 수는 있지만 이것이 새로운 것인지는 모르겠습니다. :)
Aegir는 사이트 네트워크를 관리하는 데 유용합니다. 단일 클라이언트에 대해 2000 개가 넘는 사이트를 배포하고 관리하는 데 사용했습니다.
귀하의 질문에 따르면 여러 개의 웹 헤드가있는 단일 사이트를 관리하고 싶습니다. 이 경우 Aegir이 유용하지 않을 수 있습니다. 대신 네트워킹을 지원하는 파일 시스템을 사용하는 것이 좋습니다. 이렇게하면 코드가 동기화 된 상태로 유지 될뿐 아니라 모든 노드에서 업로드를 사용할 수 있습니다.
지금까지 사람들은 NFS를 사용하여 한 서버의 파일 시스템을 다른 노드와 공유 할 수있었습니다. 불행하게도 NFS 서버가 잠기거나 죽으면 사이트를 제공 할 수 없기 때문에 단일 장애 지점이 발생합니다.
보다 안정적인 서버를 위해 iOS 성능을 약간 저하 시키려는 경우 GlusterFS를 권장 합니다. 몇 가지 프로덕션 환경에서 사용했습니다. 완벽하지는 않지만 NFS보다 낫습니다. Gluster를 사용하면 웹 헤드가 항상 로컬에서 읽은 다음 쓰기가 다른 노드로 복제됩니다.
배포 전략 측면에서 목록의 첫 번째 도구로 서두르고 있어야 합니다. drush를 사용하면 배포 단계를 자동화 할 수 있어야합니다. Jenkins를 믹스에 추가하여 배치 작업을 추적하고 실패한 경우 패턴을 식별 할 수 있도록 고려해야합니다. Capistrano는 배치와 관련된 단계를 자동화하는 데 유용 할 수 있습니다. 작업을 올바르게 수행하면 배포를 수행 한 사실을 사용자가 알지 못하도록 할 수 있습니다.