it-swarm-ko.tech

여러 프런트 엔드 서버에 코드 배포

공통 데이터베이스를 가리키는 여러로드 밸런스 서버가있는 상황이 있습니다.

정상적인 작업에서 이것은 잘 작동하며 중복성, 확장 성 등을 제공합니다.

그러나 우리는 배치가 약간 번거로운 일이라는 것을 알았습니다.

우리는 기능을 광범위하게 사용하고 있으며 배포를 자동화하려고합니다. 현재 배포는 매우 안정적이지 않습니다.

단순화 된 형태로 각 서버의 배치 스크립트에는 두 단계가 있습니다.

  1. 파일 업데이트

  2. 기능 되돌리기 (종속성, 설정 변경 등을 관리함)

일관성이없는 상태로 여러 서버에 배포하는 모범 사례가 있습니까?

1 단계와 2 단계를 서버 A에 배치하면 서버 B가 중단 될 수 있습니다. 2 단계로 진행하기 전에 두 서버에서 1 단계를 시도하면 둘 다 잠시 중단됩니다.

8
Jeremy French

Aegir 를 살펴보아야합니다. 가장 유연하고 강력한 Drupal 사이트 관리/배치 시스템) 아크로를 포괄하는 '플랫폼'을 관리 할 수 ​​있습니다. 여러 웹 헤드 또는 '클러스터'및 다양한 기타 구성.

나는 커뮤니티 문서 전반적으로 꽤 좋으며 mig5의 우수한 개요 및 입문 기사 와 그의 다른 기사를 읽는 것이 좋습니다. 이것 .

#aegir IRC 채널에서 좋은 지원을받을 수도 있습니다.

약간의 워크 플로우 변경이 될 것이므로 머리를 가져 오는 데 확실히 시간이 걸릴 수 있지만 일단 돌아간 후에는 되돌아 보지 않을 것입니다.

6
Tom Kirkpatrick

우리 회사에서는 Drupal 사이트)를 많이 유지하고 있습니다. 현재 설정은 다음과 같습니다.

  • 모든 사이트의 코드베이스에는 자체 git repo가 ​​있습니다.
  • 다음 릴리스를 위해 충분히 안정적이지 않을 새로운 기능은 git에서 자체 기능 분기를 얻습니다.

위의 내용은 대부분의 Drupal) 사이트에서 상당히 일반적입니다.

우리 회사에서 특별하게하는 것은 사용자 정의 drush 명령 인 ' Drush Debian Packaging '을 사용하여 배포 할 사이트를 데비안 패키지하는 것입니다.

Drush Debian Packaging은 Drupal 사이트를 데비안 또는 우분투 서버에 배포하는 수단으로 Drupal 사이트)의 데비안 패키지를 빌드하기위한 Drush 명령을 제공합니다.

Drush Debian Packaging은 Drupal 후크 시스템을 활용하여 사이트 요구에 가장 적합한 데비안 패키지를 만듭니다. 기능은 다음과 같습니다.

  • Apache2 및 Nginx 웹 서버에 대한 자동 가상 호스트 구성
  • /etc/cron.d의 Cron 설정
  • 사이트/기본/파일에 대한 파티션 분할을 통한 자동화 된 코드 배포
  • Dpkg debconf 설정 도구를 통한 자동화 된 구성
  • 자동화 된 배포 프로세스
  • git에서 패키지를 빌드하기위한 커스텀 Git VCS 핸들러

이것은 무엇을 의미 하는가?

릴리스를 빌드하려면 다음을 수행하십시오.

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를 설치하고 데이터베이스를 롤백하면됩니다.

이것에 대한 질문에 답변 해 드리겠습니다

4
wiifm

배포 프로세스의 어느 부분이 번거 롭거나 신뢰할 수 없습니까?

"업데이트 서버 A와 B/비 일관성"문제인 경우 푸시 기간 동안 유지 보수 페이지를 올리는 것은 어떻습니까? 유지 관리 페이지 위로, 두 웹 헤드 모두에서 코드 업데이트, one에서 유지 보수 페이지 아래로 update.php를 실행하십시오. 꽤 쉽게 스크립트 할 수 있습니다.

다른 옵션 : 실행하는 사이트의 종류에 따라 모든 사용자를 오프라인으로 시작하고 로그인/등록을 비활성화하는 "읽기 전용 모드"를 만들 수 있습니다. DB를 동일한 db 상자의 두 번째 DB에 복제하고, 프론트 엔드를 새 docroot에 복제하고, 업데이트를 수행 한 다음 Apache의 docroot를 새 프론트 엔드 docroot에 symlink하십시오. 워크 플로우는 다음과 같습니다.

  1. 읽기 전용 모드
  2. New_db로 current_db 선택
  3. cp -R current_docroot new_docroot
  4. new.yourdomain.com ==>/new_docroot
  5. new_docroot로 코드 업데이트
  6. update.php
  7. symlink/new_docroot ==> current_docroot
  8. 읽기 전용 모드가 꺼져 있습니다.
3
Entendu

Entendu가 제안한대로 변경 사항에 따라 다릅니다. 데이터베이스가 아직 업데이트되지 않은 경우 오류를 발생시키지 않고 실행할 수있는 코드 업데이트 비율은 무엇입니까? 데이터베이스 업데이트에 의존하지 않는 (그리고 더 일반적으로 만들기 위해 개발 프로세스를 약간 변경할 수있는) 것은 특별한 일이 없습니다. 가동 중지 시간을 최소화하면서 배포를 수행하려는 경우 기본 동기화 작업이 필요합니다. 이 경우 원치 않는 효과가있는 시간이 항상 존재하지만 (사이트가 읽기 전용 모드 인 경우에도) 대부분의 시간이 상당히 작을 수 있다고 생각합니다.

각 서버에서 "새"디렉토리를 미리 설정 한 다음 동시에 새 디렉토리를 가리 키도록 전환 (Entendu의 답변과 같은 심볼릭 링크 사용)과 같은 기본 최적화를 수행하여 모든 서버는 5-10 초 내에 새 파일로 전환했습니다.

데이터베이스 업데이트 문제가 남아 있습니다. 서버 한 대에서만 수행해야하는 서버 인 경우 다른 서버를 유지 관리 모드로 설정하거나로드 밸런서를 조정하여 이러한 서버가 사용되지 않도록 할 수 있습니다. 물론 사용자가 사이트에서 활동하는 동안 수행 할 수없는 경우 유지 관리 모드로 모든 것을 유지해야하지만 간단한 업데이트의 경우 약 30 초 이내에 수행 할 수 있습니다.

다른 유형의 변경 사항에 대해 다른 배포 스크립트를 사용하는 것이 좋습니다. 따라서 파일을 복사하거나 작은 데이터베이스 업데이트를 실행하거나 주요 데이터베이스를 변경하는 등 필요한 최소한의 프로세스를 실행할 수 있습니다.

파일 및 데이터베이스 업데이트를 최적화하고 개발 방식에 대한 간단한 변경 사항이 있는지 살펴보면 더 가까이 갈 수는 있지만 이것이 새로운 것인지는 모르겠습니다. :)

2
richardg

Aegir는 사이트 네트워크를 관리하는 데 유용합니다. 단일 클라이언트에 대해 2000 개가 넘는 사이트를 배포하고 관리하는 데 사용했습니다.

귀하의 질문에 따르면 여러 개의 웹 헤드가있는 단일 사이트를 관리하고 싶습니다. 이 경우 Aegir이 유용하지 않을 수 있습니다. 대신 네트워킹을 지원하는 파일 시스템을 사용하는 것이 좋습니다. 이렇게하면 코드가 동기화 된 상태로 유지 될뿐 아니라 모든 노드에서 업로드를 사용할 수 있습니다.

지금까지 사람들은 NFS를 사용하여 한 서버의 파일 시스템을 다른 노드와 공유 할 수있었습니다. 불행하게도 NFS 서버가 잠기거나 죽으면 사이트를 제공 할 수 없기 때문에 단일 장애 지점이 발생합니다.

보다 안정적인 서버를 위해 iOS 성능을 약간 저하시키려는 경우 GlusterFS 를 권장합니다. 몇 가지 프로덕션 환경에서 사용했습니다. 완벽하지는 않지만 NFS보다 낫습니다. Gluster를 사용하면 웹 헤드가 항상 로컬에서 읽히고 쓰기가 다른 노드로 복제됩니다.

배포 전략과 관련하여 목록의 첫 번째 도구로 drush 가 있어야합니다. drush를 사용하면 배포 단계를 자동화 할 수 있어야합니다. Jenkins를 믹스에 추가하여 배치 작업을 추적하고 실패한 경우 패턴을 식별 할 수 있도록 고려해야합니다. Capistrano는 배치와 관련된 단계를 자동화하는 데 유용 할 수 있습니다. 작업을 올바르게 수행하면 배포를 수행 한 사실을 사용자가 알지 못하도록 할 수 있습니다.

0
skwashd