홈페이지>웹사이트 구축 리소스>웹사이트 데이터
다운로드
대지 상태
istio.io
예비. istio.io
Archive.istio.io

istio.io

이 저장소에는 istio.io 및 preliminary.istio.io의 소스 코드가 포함되어 있습니다.

전체 ISTIO 프로젝트 및 우리와 연락하는 방법에 대해 알아 보려면 주요 ISTIO README 파일을 참조하십시오. ISTIO 구성 요소에 기여할 수있는 방법을 알아 보려면 ISTIO 기부 지침을 참조하십시오.

  • 편집 및 빌딩
  • 버전 및 릴리스
    • 버전화가 작동하는 방법
    • 컨텐츠를 즉시 게시합니다
    • 주요/사소한 릴리스 생성
    • 패치 릴리스 생성
  • 문서 내용을 테스트합니다
  • 다국어 지원
  • 정기적 인 유지 보수
  • 사용자 정의 페이지

편집 및 빌딩

이 Repo의 컨텐츠를 편집하고 빌드하는 방법을 배우려면 페이지 작성 및 편집을 참조하십시오.

버전 및 릴리스

Istio는 공개 사이트의 두 가지 변형을 유지합니다.

  • istio.io는 제품의 현재 릴리스에 대한 문서를 보여주는 주요 사이트입니다. istio.io/archive에는 제품의 이전 릴리스에 대한 문서의 스냅 샷이 포함되어 있습니다. 이는 여전히 이러한 이전 릴리스를 사용하는 고객에게 유용합니다.

  • Preliminary.istio.io에는 제품의 다음 릴리스에 대한 적극적으로 업데이트 된 문서가 포함되어 있습니다.

사용자는 각 페이지의 오른쪽 상단에있는 기어 메뉴를 사용하여 사이트의 다양한 변형을 사소하게 탐색 할 수 있습니다. 두 사이트 모두 NetLify에서 호스팅됩니다.

버전화가 작동하는 방법

  • 문서 변경은 주로 istio.io의 마스터 지점에 최선을 다하고 있습니다. 이 지점에 최신 변경 사항은 예선 .istio.io에 자동으로 반영됩니다.

  • istio.io의 내용은 최신 릴리스 -xxx 지점에서 가져옵니다. 사용되는 특정 분기는 istio.io netlify 프로젝트의 구성에 의해 결정됩니다.

컨텐츠를 즉시 게시합니다

마스터 브랜치에 대한 업데이트를 확인하면 예선. istio.io를 자동으로 업데이트하며 다음에 릴리스가 생성 될 때만 ISTIO.IO에만 반영됩니다. 이는 향후 몇 주가 될 수 있습니다. istio.io에 즉시 변경을 원한다면 마스터 브랜치와 현재 릴리스 브랜치 ( release-1.7 release-<MAJOR>.<MINOR> .

이 프로세스는 인프라에 의해 자동으로 처리 될 수 있습니다. PR을 마스터 브랜치에 제출하고 cherrypick/release-<MAJOR>.<MINOR> 로 PR에 주석을 달면 PR이 마스터로 병합 되 자마자 지정된 릴리스 브랜치로 병합됩니다.

주요/사소한 릴리스 생성

새 문서 버전을 만드는 데 필요한 단계는 다음과 같습니다. 현재 버전의 istio가 1.6이라고 가정하고 개발중인 1.7을 소개하려고합니다.

istio 소스 코드가 분기 될 때

런을 make prepare-1.7.0 . 이렇게하면 새로운 ISTIO 소스 브랜치의 최신 참조 문서를 content/en/docs/reference 폴더로 가져옵니다.

석방 당일에 접근합니다

  1. 공식 릴리스 전에 드라이 런을 위해 Run make release-1.7.0-dry-run 은 새로운 지점 release-1.7-dry-run 만 생성하고 다른 지점을 만지지 않습니다.

  2. 출시 당일에 make release-1.7.0 실행하십시오. 이로 인해 대상은 master 및 release-1.6 의 일부 변수를 변경하고 새 버전에 대한 새 지점 release-1.7 만듭니다.

  3. NetLify의 istio.io 프로젝트로 이동하여 다음을 수행하십시오.

    • 이전 릴리스 브랜치에서 새 릴리스 브랜치로 구축 된 브랜치 release-1.7-dry-run 변경 release-1.7 .

    • 즉각적인 재건 및 재배치를 트리거하려는 옵션을 선택하십시오.

    • 배포가 완료되면 istio.io를 탐색하고 모든 것이 좋아 보이는지 확인하십시오.

  4. Google 사용자 정의 검색 엔진으로 이동하여 다음을 수행하십시오.

    • 고급 탭에서 istio.io CSE 컨텍스트 파일을 다운로드하십시오.

    • 이전 릴리스의 버전 번호가 포함 된 파일 상단에 새 FacetItem을 추가하십시오. 이 경우 이것은 V1.6 입니다.

    • 업데이트 된 CSE 컨텍스트 파일을 사이트에 업로드하십시오.

    • 설정 섹션에서 이전 릴리스의 아카이브 디렉토리를 다루는 새 사이트를 추가하십시오. 이 경우 사이트 URL은 istio.io/v1.6/* 입니다. 이 사이트의 레이블을 위에서 만든 패싯 항목의 이름으로 설정하십시오 (이 경우 V1.6 ).

패치 릴리스 생성

패치 릴리스 며칠 전에 릴리스 관리자는 DOC WG에 릴리스가 구축되었으며 장기 실행중인 자격 테스트를 시작하고 있음을 알려야합니다. 현재 DOC 자동화 테스트를 이동하여 새 릴리스를 사용하여 자동 DOC 테스트 패스를 확인하십시오.

새 릴리스로 이동하려면 (패치 릴리스 브랜치에 있는지 확인) :

  1. run go get istio.io/istio@AXY && go mod tidy .

  2. go.* 변경.

새 패치 릴리스를 작성하면 몇 가지 파일을 수정해야합니다.

  1. data/args.yml 편집하고 full_version 필드를 "AXY" 로 변경하십시오. 이것은 current 릴리스 패치에만 필요합니다.

  2. Markdown 파일 content/en/news/releases/AXx/announcing-AXY/index.md 편집하여 릴리스의 릴리스 노트를 작성하십시오. 릴리스의 변경 사항을 설명하는 곳입니다. 콘텐츠 및 레이아웃과 같은 다른 기존 파일을보십시오.

  3. 최신 참조 문서를 얻으려면 make update_ref_docs 실행하십시오. 일반적으로 이것은 current 릴리스 패치에만 필요합니다. 이전 릴리스에 필요한 경우 아카이브 업데이트를 참조하십시오.

아카이브 업데이트

최신 분기 (예 : release-1.7:archive/v1.6 )의 아카이브 버전이 이전 릴리스 브랜치의 변경으로 인해 업데이트되어야하는 경우 (이 경우 release-1.6 ) master 브랜치에서 구식 release-1.6 make build-old-archive-1.6.0 수 있으며 master 브랜치에서 이전 아카이브를 대체 할 수 있습니다. 이 업데이트를 istio.io에 반영 해야하는 경우 PR은 current 릴리스를 위해 지점에 벚꽃을 고정시킬 수 있습니다.

주어진 릴리스 스트림에 대한 테스트 참조 업데이트

release-1.6 으로 시작하는 릴리스 스트림에는 테스트 내용에 대한 테스트가 포함되어 있습니다. 각 릴리스는 특정 istio 버전/커밋에 대한 테스트입니다. 릴리스 팀에 1.xy 장기적으로 테스트 할 준비가 된 빌드가 있으면 Docs 팀에 와서 해당 릴리스 런에 대한 테스트를 시작하여 빌드에 대항하여 실행해야합니다.

public 및 private 두 가지 유형의 빌드가 있습니다. 일반 개발 및 릴리스 빌드는 공개 저장소에서 구축되며 공개적으로 액세스 가능한 저장소에 이미지가 있으며 public 로 간주됩니다. Private 빌드는 출시 전에 많이 공개 할 수없는 빌드입니다. 일반적으로 릴리스는 CVE에 대해 2 주 안에 발생한다는 사전 통지입니다. 실제 릴리스 전에 아무것도 공개 할 수 없으므로 소스 및 제작 된 이미지는 개인 저장소에 있습니다. 소스와 이미지가 비공개이므로 공개적으로 출시 될 때까지 실제로 이동할 수 없으므로 istio.io에서 릴리스에 대한 초기 테스트는 없습니다. private 빌드의 차이점은 우리가 테스트 한 이미지가 public gcr.io 저장소에서 결코 만들어지지 않았 으므로이 경우 Docker.io 이미지를 사용한다는 것입니다. 왜 우리가 Docker.io의 릴리스 이미지를 항상 사용하지 않는지 물어볼 수 있습니다. public 빌드가 출시되기 전에 테스트하고 싶기 때문에 이미지는 Docker.io에 아직 존재하지 않습니다.

공개 빌드 용 :

  1. https://gcsweb.istio.io/gcs/istio-release/releases/1.xy/manifest.yaml 파일에서 빌드에 사용 된 istio/istio 커밋을 얻으십시오.
  2. 릴리스 브랜치에서 : Run go get istio.io/istio@commit && go mod tidy .

개인 빌드의 경우 (이 건물이 릴리스 된 후에 이루어짐) :

  1. 릴리스 브랜치 : Run go get istio.io/[email protected] && go mod tidy .

두 빌드 모두 Hub/Tag가 makefile.core.mk에서 올바른지 확인하려고합니다 (개인 또는 공개 빌드를 사용하는 경우에 따라 변경됨). 다음과 유사한 섹션을 찾으십시오. 

 # If one needs to test before a docker.io build is available (using a public test build),
# the export HUB and TAG can be commented out, and the initial HUB un-commented
HUB ?= gcr.io/istio-testing
# export HUB ?= docker.io/istio
# export TAG ?= 1.7.3

공개 빌드의 경우 export HUB/TAG S는 무책임하고 올바른 값을 갖습니다. 비공개 빌드 또는 master 브랜치의 경우 허브가 무책임합니다.

마지막으로, 변경 사항과 함께 PR을 생성하고 제출하면 PR에서 테스트 결과를 볼 수 있습니다. 일반적으로 PR은 릴리스가 출시 될 때까지 실제로 합병되지 않습니다 (때로는 릴리스를위한 여러 빌드가 있습니다).

문서 내용을 테스트합니다

istio 사이트의 많은 문서는 istio가 릴리스에서 릴리스로 진화함에 따라 계속 작동하거나 작동하지 않을 수도있는 명령을 사용하여 기능을 보여줍니다. 문서화 된 지침이 가능한 한 적은 연속 수동 테스트를 최신 상태로 유지하기 위해 이러한 문서의 테스트를 자동화하기위한 프레임 워크를 만들었습니다.

테스트 할 수있는 istio.io의 모든 페이지에는 페이지 제목 아래에 PAGE TEST 표시가 포함됩니다. 예를 들어:

PAGE TEST

녹색 확인 마크는 페이지에서 자동화 된 테스트를 사용할 수 있음을 나타냅니다. 페이지는 최신 상태이며 문서화 된대로 작동합니다.

반면에 그레이 X는 아직 페이지에 사용할 수있는 자동 테스트가 없음을 의미합니다. 하나를 만들도록 도와 주시면 감사하겠습니다! 우리의 목표는 결국 Istio 사이트에 게시 된 모든 테스트 가능한 문서에 대해 자동 테스트를 수행하는 것입니다.

자세한 내용은 테스트 readme를 참조하십시오.

다국어 지원

사이트는 여러 언어로 변환됩니다. 진실의 근원은 영어 콘텐츠이며 다른 언어는 파생되므로 약간 뒤쳐지는 경향이 있습니다. 각 사이트 언어는 자체 자체 포함 된 컨텐츠 디렉토리 및 번역 테이블 파일을 제공합니다. 언어는 국제 2 글자 언어 코드를 사용하여 식별됩니다. 기본 사이트 내용은 content/<language code> (예 : content/en )에 있으며 번역 테이블은 i18n<language code>.toml (예 : i18n/en.toml )의 Toml-Format 파일입니다.

번역을 시작하는 것은 매우 간단합니다.

  • 언어에 대한 content/en 디렉토리의 전체 사본을 작성하십시오. 예를 들어, 프랑스어 번역을하는 경우 content/en content/fr 에 복사합니다.

  • 새 컨텐츠 디렉토리의 모든 링크를 업데이트하여 영어 콘텐츠 대신 콘텐츠 디렉토리를 가리 키십시오. 예를 들어, 프랑스어 번역을 수행하는 경우 [a doc](/docs/a/b/c) 와 같은 링크를 [a doc](/fr/docs/a/b/c) 로 변경합니다.

  • 모든 컨텐츠 페이지의 전면에서 모든 aliases 지시문을 제거하십시오. 별명은 페이지를 새 위치로 이동할 때 사용되므로 새로운 콘텐츠에 바람직하지 않습니다.

  • 언어에 대한 i18n/en.toml 파일의 사본을 만듭니다. 예를 들어, 프랑스어 번역을하는 경우 i18n/en.toml i18n/fr.toml 에 복사합니다. 이 파일에는 메뉴 및 기타 표준 자료와 같은 사이트 인프라에서 표시되는 텍스트가 포함되어 있습니다.

  • hugo.toml 파일을 편집하여 새 언어를 나열하십시오. [languages] 항목을 검색하고 새 항목 만 추가하십시오. 이것은 Hugo 사이트 생성기에게 콘텐츠를 처리하도록 지시합니다.

  • 파일 scripts/lint_site.sh 편집하고 check_content 검색하십시오. 새 컨텐츠 디렉토리에 대해 check_content 에 다른 호출을 추가하십시오. 이를 통해 Linting 규칙이 새 컨텐츠에 적용되도록합니다.

  • src/ts/lang.ts 파일을 편집하고 새 언어를 추가하십시오. 이렇게하면 Preliminary.istio.io에서 사용할 수있는 언어 토글 버튼에 언어가 추가되며 언어 선택 메뉴에서 언어가 지원되도록합니다.

  • ISTIO GitHub 관리자를 통해 언어를위한 새로운 관리자 팀을 만들 수 있습니다. 프랑스어의 경우, 이것은 WG - Docs Maintainers/French 입니다.

  • 파일 CODEOWNERS 편집하고 언어에 대한 항목을 추가하여 번역 된 컨텐츠 및 번역 테이블 파일을 통해 소유 한 새 팀을 제공합니다.

그런 다음 이러한 모든 변경 사항을 커밋 할 수 있으며 컨텐츠와 번역 파일을 순전히 점진적으로 번역 할 수 있습니다. 사이트를 구축하면 <url>/<language code> 에서 콘텐츠를 찾을 수 있습니다. 예를 들어, 모든 것을 확인한 후에는 프랑스어 번역을하고 있다면 https://preliminary.istio.io/fr 에서 콘텐츠를받을 수 있어야합니다.

번역이 완료되고 세상에 게시 할 준비가되면 몇 가지 다른 변경 사항이 있습니다.

  • 파일 layouts/index.redir 편집. translated sites 를 검색하고 언어에 대한 줄을 추가하십시오. 이로 인해 사용자는 처음으로 사이트에 오는 것이 자신에게 적합한 번역 된 컨텐츠로 자동 리디렉션됩니다. 프랑스어의 경우 : 이것은 다음과 같습니다. 

     /  /fr   302  Language=fr

  • FHE 파일 layouts/partials/headers.html 편집. switch-lang 검색하면 언어 선택 메뉴의 정의가 있습니다. 새 언어에 대한 줄을 추가하십시오.

그리고 그게 다야.

정기적 인 유지 보수

우리는 사이트의 전반적인 품질을 돕기 위해 여러 가지 불변량이 유지되도록 많은 수표를 보유하고 있습니다. 예를 들어, 우리는 깨진 링크를 확인하지 못하고 맞춤법 검사를합니다. 자동화를 통해 체계적으로 확인하기 어려운 것들이 있으며, 대신 모든 것이 잘 진행되도록 인간이 한동안 검토해야합니다.

사이트의 주요 릴리스 마다이 목록을 실행하는 것이 좋습니다.

  • GitHub의 istio Repos에 대한 참조가 지점 이름을 하드 코드하지 않도록하십시오. 모든 Markdown 파일에서 /release-1 또는 /master

  • 거기에 없어야 할 단어에 대한 .Strelling 파일을 검토하십시오. 특히 유형 이름은 여기에 들어오는 경향이 있습니다. 유형 이름은 사전에 있지 않아야하며 대신 backticks 로 표시되어야합니다. 사전에서 항목을 제거하고 나오는 맞춤법 검사 오류를 수정하십시오.

  • 적절한 대문자를 보장하십시오. 문서 제목은 완전히 대문자화되어야합니다 (예 : "이것은 유효한 제목입니다"), 섹션 제목은 첫 번째 문자 대문자를 사용해야합니다 (예 : "이것은 유효한 제목입니다").

  • istio github 저장소에서 파일을 참조하는 사전 형식화 된 텍스트 블록이 @@ syntax를 사용하여 컨텐츠에 대한 링크를 생성하는지 확인하십시오. 문맥은 여기를 참조하십시오.

확장하다
추가 정보
관련 애플리케이션
추천
관련 정보 전체