온디바이스의 워크로드 증명에는 확정적인 빌드가 필요합니다. 맞춤설정 (ODP) 신뢰할 수 있는 실행 환경 (TEE), 다음에서 공개적으로 사용 가능 Confidential Space (CS)로서의 Google Cloud
워크로드 이미지는 다음에서 사용할 수 있는 확정 이미지 해시를 생성해야 합니다. 워크로드 증명을 위한 CS (NIST의 RFC 9334 원격 증명 사용) 절차 (RATS) 아키텍처 참조).
이 문서에서는 결정론적 모델의 구현 및 지원에 대해 설명합니다. 빌드를 odp-federatedcompute 저장소 ODP 애그리게이터 및 모델 업데이터 서비스는 Confidential Space. 저장소는 모든 Google Cloud 제품에 대해 Google Cloud 서비스를 사용하는 것이 좋습니다
확정적인 빌드
결정론적 빌드는 두 가지 주요 구성요소로 구성됩니다.
- 필수 바이너리의 컴파일 여기에는 jar, 공유 라이브러리, 메타데이터 등이 있습니다
- 기본 이미지 및 런타임 종속 항목 런타임 환경의 기본 사용되는 이미지 파일 시스템입니다.
현재 ODP Federated Compute 저장소는 다음과 같은 유형의 워크로드:
- Java + Spring 워크로드
<ph type="x-smartling-placeholder">
- </ph>
- 태스크 할당, 태스크 관리, 수집기
- JNI TensorFlow 워크로드를 사용하는 Java + Spring
<ph type="x-smartling-placeholder">
- </ph>
- ModelUpdater, 애그리게이터
- Python 워크로드
<ph type="x-smartling-placeholder">
- </ph>
- TaskBuilder
종속 항목
다음 목록은 ODP에서 결정성을 유지하기 위해 사용하는 종속 항목입니다. 및 가용성:
- Bazel
- GitHub
- Maven
- PyPi
- Debian 스냅샷
- DockerHub 레지스트리
- Google Container Registry(GCR)
확정적인 워크로드
모든 워크로드는 Bazel을 사용하여 컴파일되며 다음을 사용하여 빌드된 언어별 도구 모음 및 컨테이너 이미지 rules_oci WORKSPACE 파일 해당하는 버전과 해시로 모든 종속 항목을 정의합니다.
Debian 스냅샷
모든 워크로드 이미지는 제공된 dockerfile Debian 스냅샷을 기반으로 빌드됩니다. 데비안 스냅샷은 확정적인 안정적인 저장소 스냅샷을 제공합니다.
- 시스템 헤더 및 라이브러리
- 시스템 아키텍처
<ph type="x-smartling-placeholder">
- </ph>
- linux_x86_64
- Debian
- C++ 컴파일러
<ph type="x-smartling-placeholder">
- </ph>
- 사전 빌드된 Clang+LLVM 16명
Java Spring 워크로드
Bazel's
remotejdk_17
:
는 컴파일을 위한 밀폐 Java를 제공하는 데 사용됩니다. 다른 Java 종속 항목은
WORKSPACE에서 관리 및 정의됨
파일을 참고하세요.
Java Spring 워크로드는
<service>_application.jar
jar에는 다음이 포함됩니다.
- Java 클래스 파일
META-INF/
- Bazel 매니페스트 데이터
build-data.properties
- Bazel 빌드 데이터
BOOT-INF/
- 패키징된 jar 종속 항목, 다음으로 생성: rules_spring
이미지 레이어
Java Spring 워크로드 이미지는 두 가지 레이어로 구성됩니다.
- 기본 이미지 레이어
<ph type="x-smartling-placeholder">
- </ph>
- Java 기본 이미지:
gcr.io/distroless/java17-debian11
드림
- Java 기본 이미지:
- 워크로드 레이어
<ph type="x-smartling-placeholder">
- </ph>
binary_tar.tar
<service>_application.jar
이미지 구성
- 진입점
<ph type="x-smartling-placeholder">
- </ph>
java -jar <service>_application.jar
JNI TensorFlow 워크로드
JNI TensorFlow 워크로드는 Java Spring 워크로드를 기반으로 빌드됩니다. 가 밀폐 Clang+LLVM Bazel 도구 모음은 사전 빌드된 Clang+LLVM을 사용하여 제공됩니다. 16 sysroot에서 제공하는 Debian 스냅샷 이미지에서 기계어 코드를 컴파일합니다.
JNI 워크로드는 libtensorflow.so
라는 공유 라이브러리에 함께 컴파일됩니다.
<service>_application.jar
로 교체합니다.
이미지 레이어
JNI TensorFlow 워크로드 이미지는 여러 레이어로 구성됩니다.
- 기본 이미지 레이어
<ph type="x-smartling-placeholder">
- </ph>
- Java 기본 이미지:
gcr.io/distroless/java17-debian11
드림
- Java 기본 이미지:
- Debian 패키지 종속 항목 레이어 레이어는 deb를 사용하여 생성됩니다.
debian-snapshot에서 다운로드하여 이미지 레이어로 리패키징
<ph type="x-smartling-placeholder">
- </ph>
libc++1-16_amd64.tar
libc++abi1-16_amd64.tar
libc6_amd64.tar
libunwind-16_amd64.tar
libgcc-s1_amd64.tar
gcc-13-base_amd64.tar
- 워크로드 레이어
<ph type="x-smartling-placeholder">
- </ph>
binary_tar.tar
<service>_application.jar
libtensorflow-jni.so
libaggregation-jni.so
이미지 구성
- 라벨 (TEE 내에서 실행되도록 빌드된 이미지만 해당)
<ph type="x-smartling-placeholder">
- </ph>
"tee.launch_policy.allow_env_override": "FCP_OPTS"
FCP_OPTS
환경 변수를 설정할 수 있습니다. 기밀 Space를 사용합니다. 워크로드는 시작 시FCP_OPTS
를 사용하여 구성합니다. 필수 매개변수입니다.FCP_OPTS
환경 변수는 이미지가 실행될 때 설정됩니다. (빌드 대신)를 사용하여 빌드 결정론을 유지합니다.
"tee.launch_policy.log_redirect": "always"
"tee.launch_policy.monitoring_memory_allow": "always"
- 진입점
<ph type="x-smartling-placeholder">
- </ph>
java -Djava.library.path=. -jar <service>_application.jar
Python 워크로드
Bazel의 rules_python은 밀폐 Python 3.10 도구 모음을 제공합니다. 잠긴 pip 요구사항 파일 pip 종속 항목의 확정적인 가져오기에 사용됩니다. Debian 스냅샷 이미지를 사용하면 플랫폼을 기반으로 확정적 분포를 가져올 수 있습니다. 호환성 소스 배포 컴파일을 위한 C++ 도구 모음을 제공합니다.
Python 워크로드는 다운로드한 pip 패키지 모음으로 패키징됩니다. Python 3.10 배포, ODP Python 소스 코드, Python 스타트업 있습니다.
<service>.runfiles/
- Python 배포는
python_x86_64-unknown-linux-gnu/
에 저장됩니다. - 소스 코드는
com_google_ondevicepersonalization_federatedcompute/
- PIP 패키지는
pypi_<dependency_name>/
에 저장됩니다.
- Python 배포는
<service>.runfiles_manifest
<service>.runfiles/
디렉터리의 매니페스트 파일
<service>
- 실행 파일을 사용하여 Python 워크로드를 실행하는 Python 스크립트
이미지 레이어
Python 워크로드 이미지는 네 가지 레이어로 구성됩니다.
- 기본 이미지 레이어
<ph type="x-smartling-placeholder">
- </ph>
- Python 기본 이미지 python:slim
- 인터프리터 레이어
<ph type="x-smartling-placeholder">
- </ph>
interpreter_layer.jar
<service>/<service>.runfiles/python_x86_64-unknown-linux-gnu/**
- 패키지 레이어
<ph type="x-smartling-placeholder">
- </ph>
packages_layer.jar
<service>/<service>.runfiles/**/site-packages/**
- 워크로드 레이어
<ph type="x-smartling-placeholder">
- </ph>
app_tar_manifest.tar
- 소스 코드, 시작 스크립트, 매니페스트를 포함합니다.
<service>/<service>.runfiles_manifest
<service>/<service>
<service>/<service>.runfiles/com_google_ondevicepersonalization_federatedcompute/**
- 소스 코드, 시작 스크립트, 매니페스트를 포함합니다.
이미지 구성
- 진입점
<ph type="x-smartling-placeholder">
- </ph>
/<service>/<service>
이미지 빌드
워크로드를 선택했다면 이제 이미지
기본 요건
절차
이미지는 제공된 dockerfile을 엽니다. 최종 결정론적 이미지를 빌드하는 데 도움이 되도록 두 개의 스크립트가 제공됩니다.
- docker_run.sh
docker_run.sh
가 dockerfile에서 Docker 이미지를 빌드하고 마운트합니다. 호스트 Docker 데몬을 마운트하고 bash 명령어를 제공합니다 bash 명령 전에 전달되는 모든 변수는 Docker 실행 플래그로 취급됩니다
- build_images.sh
build_images.sh
는 모든 이미지에bazel build
를 실행하고 다음을 출력합니다. 이미지 해시를 생성합니다.
모든 이미지 빌드
./scripts/docker/docker_run.sh "./scripts/build_images.sh"
각 출시 버전의 예상 이미지 해시는 다음에서 확인할 수 있습니다. odp-federatedcompute GitHub 버전을 참고하세요.
이미지 게시
게시는 다음을 사용하여 구성됩니다. oci_push Bazel 규칙 각 서비스에 대해 대상 저장소를 다음과 같이 구성해야 합니다. 전체:
- 애그리게이터
- 수집기
- model_updater
- task_assignment
- task_management
- task_scheduler
- task_builder
단일 이미지 게시
단일 이미지를 게시하려면 다음 안내를 따르세요.
./scripts/docker/docker_run.sh "bazel run //shuffler/services/<servicename_no_underscore>:<servicename_with_underscore>_image_publish"
빌드된 이미지
빌드된 모든 이미지는 제작자가 저장하고 호스팅해야 합니다(예: GCP Artifact Registry