데모 배포

사전 요구 사항

terraform/versions.tf의 최소 버전인 Terraform — >= 1.8, 프로바이더 정의 함수와 VIP를 보호하는 check 블록을 위해 필요합니다.
xcsh 프로바이더. 버전을 고정하는 것은 없습니다: .terraform.lock.hcl은 gitignore되어 있고 제약 조건은 상한이 없는 최소값이므로, 모든 init은 가장 최근에 게시된 릴리스를 확인합니다. 이는 프리릴리스 프로젝트를 위한 의도적인 선택입니다 — 데모는 회귀를 숨기는 오래된 버전에 머무르기보다 프로바이더 회귀에서 실패해야 합니다.
var.expected_xc_tenant에 지정된 테넌트에 대한 F5 XC API 자격 증명, XCSH_API_TOKEN으로 내보내기(또는 P12/PEM 쌍). 자격 증명만 내보내고 URL은 절대 내보내지 마십시오 — 아래를 참조하십시오.
리소스 그룹, VNet, Route Server 및 VM을 생성할 권한이 있는 Azure 자격 증명.
앱 계층을 위한 기존 F5 XC 네임스페이스. 배포는 이를 읽기만 하고 생성하거나 삭제하지 않으므로, 관련 없는 데모를 담고 있는 네임스페이스가 이 스택의 destroy 목록에 오를 수 없습니다.

~/.terraformrc에 xcsh에 대한 dev_overrides 블록이 있으면, 모든 로컬 Terraform 명령은 해당 디렉터리의 바이너리를 사용하고 버전 제약 조건과 lock 파일 모두를 무시합니다. 며칠 지난 빌드만으로도, 게시된 프로바이더에 대해서는 완벽하게 유효한 구성에서 Blocks of type "…" are not expected here 오류가 발생할 수 있습니다.

기본 경로에서 제외하고 프로바이더를 개발할 때만 선택적으로 사용하십시오:

mv ~/.terraformrc ~/.terraformrc.provider-dev
TF_CLI_CONFIG_FILE=~/.terraformrc.provider-dev terraform plan   # when you mean it

기본값이 없는 두 값 제공

다른 모든 변수에는 동작하는 기본값이 있고, 모든 객체 이름은 var.component에서 파생됩니다. 두 개는 의도적으로 기본값 없이 남겨져 있습니다:

cd terraform
cp terraform.tfvars.example terraform.tfvars

변수	기본값이 없는 이유
`origin_ip`	어떤 기본값이든 특정한 하나의 머신을 가리킵니다. 오래된 값은 새 배포의 트래픽을 실패시키는 대신 다른 사람의 호스트로 보냅니다.
`lb_domain`	로드 밸런서는 `Host`로 매칭하므로, 모든 요청이 반드시 보내야 하는 값입니다. 이는 배포를 실행하는 사람에게 속합니다.

둘 다 형식이 검증되므로, 오타는 데모가 아니라 plan에서 실패합니다.

terraform.tfvars는 gitignore되어 있으며, 계속 그렇게 유지되어야 합니다: 구독 id와 엔지니어별 값을 담고 있습니다.

테넌트는 셸이 내보내는 값이 아니라 구성입니다

var.expected_xc_tenant가 테넌트의 이름을 지정하며, 테넌트가 명시되는 유일한 곳입니다. providers.tf는 이 값에서 xcsh 프로바이더의 api_url을 파생하며, 이는 환경의 XCSH_API_URL을 의도적으로 재정의합니다. 그리고 terraform/main.tf의 postcondition은 환경이 다른 테넌트를 지정할 때 plan을 실패시킵니다.

상태를 변경하는 어떤 것도 실행하지 않고 두 값 중 어느 쪽이든 읽을 수 있습니다:

terraform output -raw xc_tenant       # what the deployment targets
terraform output -raw xc_env_tenant   # what your shell claims — diagnostic only

f5-sales-demo
f5-sales-demo

데모는 하나의 테넌트에서 구축되었습니다. 이후 자격 증명 파일이 다른 테넌트의 XCSH_API_URL을 내보내기 시작했고, 이후의 apply는 해당 테넌트에 대한 토큰을 발급했으며, CE VM은 거기에 재등록되고 원래 등록은 버려졌습니다. 그 사이의 모든 plan은 깨끗했습니다. 구성에서 테넌트에 대해 어떤 의견도 갖고 있지 않았기 때문입니다 (issue 696, PR 697에서 수정됨). 복구를 위해서는 잘못된 테넌트의 스택을 파괴하고 올바른 테넌트에서 다시 구축해야 했습니다.

스스로를 설명하지 않기 때문에 반드시 인식해야 하는 증상: 다른 테넌트에 대해 발급된 토큰은 고정된 엔드포인트에서 아무 설명 없는 401로 실패하는데, 이는 정확히 만료된 자격 증명처럼 보입니다. 정상이라고 믿는 자격 증명이 401을 반환하면, 다른 토큰을 발급하기 전에 위의 두 출력을 비교하십시오.

적용

초기화. 백엔드 구성은 커밋되어 있지 않으므로, 직접 제공하십시오.
Terminal window
```
terraform init -backend-config=backend.hcl
```
첫 번째 apply. 이는 Azure, CE 사이트, 등록 토큰을 구축하고 CE를 부팅합니다.
Terminal window
```
terraform apply
```
CE가 등록된 후 다시 apply. 이는 선택 사항이 아니며, 그 이유는 직접 발견하는 것이 아니라 아래에 설명되어 있습니다.
Terminal window
```
terraform apply
```

그런 다음 누군가에게 보여주기 전에 정상 상태 확인을 진행하십시오.

등록 승인은 자동화되어 있지만, apply는 여전히 2단계입니다

등록 승인에는 더 이상 콘솔에서의 사람 개입이 필요하지 않습니다: xcsh_registration_approval 리소스가 이를 수행하며, 사이트 모듈이 어떤 등록을 승인할지 결정합니다.

그럼에도 배포가 손을 대지 않는 단일 apply가 되는 것은 아니며, 첫 실행을 지켜보고 실패했다고 결론짓기 전에 그 이유를 이해할 가치가 있습니다:

CE의 등록 객체는 **r-<uuid>**라는 이름을 갖습니다. 사이트 이름을 따르지 않으므로, plan 시점에는 그 이름을 예측할 수 없습니다.
등록은 VM이 부팅되고 vpm이 등록한 후에만 존재합니다.
따라서 첫 번째 apply는 승인을 전혀 계획하지 않습니다. CE가 등록된 후 다시 apply하면 승인이 생성됩니다.

terraform/main.tf는 파일 상단에 이 순서를 문서화하고 있으며, 그것이 권위 있는 버전입니다 — 배포 순서는 그것을 구현하는 코드와 함께 존재합니다.

운영자 SSH는 빌드 시점의 결정입니다

배포는 로그인 셸이 Site CLI인 어플라이언스 admin 계정에 운영자 키를 씁니다. 이는 첫 부팅 시 한 번 실행되는 cloud-init write_files에 의해 작성됩니다.

custom_data는 교체 전용이므로, 실행 중인 CE에 이를 도입하면 모든 CE VM이 교체됩니다. 이는 구성 변경이 아니라 플릿 재구축입니다. cloud-init 템플릿의 다른 모든 것도 마찬가지이며 — 주석까지 포함됩니다. custom_data가 렌더링된 파일의 base64encode이기 때문입니다.

예전에는 더 나빴습니다: 교체된 CE는 결코 재등록할 수 없었는데, 파괴된 노드의 등록이 여전히 컨트롤 플레인의 고유 (tenant, cluster_name, hostname) 인덱스를 보유하고 있었기 때문입니다 — 그리고 플릿이 다운된 전체 기간 동안 terraform plan은 “No changes”를 보고했습니다. 복구에는 두 번의 전체 재구축이 필요했습니다. 이는 수정되었습니다 (issue 674, PR 693로 종료됨): 사이트 객체의 라이프사이클이 이제 CE VM 인스턴스에 연결되어 있으므로, VM을 교체하면 사이트도 교체되고, 사이트를 삭제하면 교체 노드가 부팅되기 전에 그 등록도 함께 삭제됩니다.

이를 다른 곳에 도입하려는 사람은 먼저 SSH 페이지를 읽어야 합니다.

해체

terraform destroy

앱 네임스페이스는 살아남습니다: 읽기만 하고 관리하지 않으므로, destroy는 관련 없는 데모를 담고 있는 네임스페이스를 함께 제거할 수 없습니다. 리소스 그룹의 나머지 모든 것은 제거됩니다.