این صفحه به‌وسیله ‏Cloud Translation API‏ ترجمه شده است.

ساخت قطعی محاسبه فدرال شخصی سازی روی دستگاه

ساخت‌های قطعی برای تأیید حجم کار در محیط اجرای معتمد شخصی‌سازی دستگاه (ODP) مورد نیاز است که به‌صورت عمومی در Google Cloud به‌عنوان فضای محرمانه (CS) در دسترس است.

تصاویر حجم کاری باید یک هش تصویر قطعی ایجاد کنند که می تواند توسط CS برای تأیید بار کاری استفاده شود (که از معماری RFC 9334 NIST Remote ATtestation procedureS (RATS) Architecture استفاده می کند).

این سند به پیاده سازی و پشتیبانی از ساخت های قطعی در مخزن محاسباتی odp-federated می پردازد. خدمات ODP Aggregator و Model Updater در فضای محرمانه اجرا خواهد شد. مخزن از ساخت های قطعی برای همه سرویس های ما پشتیبانی می کند، که برای موارد استفاده تولید مورد نیاز است.

ساخت های قطعی

ساختارهای قطعی از دو جزء اصلی تشکیل شده است:

کامپایل باینری های مورد نیاز این شامل شیشه ها، کتابخانه های مشترک و ابرداده می شود.
وابستگی های تصویر پایه و زمان اجرا. تصویر پایه محیط اجرا که برای اجرای باینری های کامپایل شده استفاده می شود.

در حال حاضر، مخزن محاسبات فدرال ODP از انواع بارهای کاری زیر پشتیبانی می کند:

بارهای کاری جاوا + Spring
- TaskAssignment، TaskManagement، Collector
Java + Spring با بارهای کاری تنسورفلو JNI
- Model Updater، Aggregator
بارهای کاری پایتون
- TaskBuilder

وابستگی ها

فهرست زیر وابستگی هایی است که ODP برای حفظ جبر و در دسترس بودن به آنها تکیه می کند:

بازل
GitHub
ماون
PyPi
عکس های فوری دبیان
رجیستری DockerHub
Google Container Registry (GCR)

بارهای کاری قطعی

همه بارهای کاری با استفاده از Bazel با زنجیره های ابزار خاص زبان و تصاویر ظرف ساخته شده با استفاده از rules_oci کامپایل می شوند. فایل WORKSPACE تمام وابستگی ها را با نسخه ها و هش های مربوطه تعریف می کند.

عکس های فوری دبیان

همه تصاویر حجم کاری باید در فایل docker ارائه شده ساخته شده در بالای یک عکس فوری دبیان ساخته شوند. عکس‌های فوری دبیان یک عکس فوری مخزن پایدار با قطعی ارائه می‌کنند:

سرصفحه ها و کتابخانه های سیستم
معماری سیستم
- linux_x86_64
- دبیان
کامپایلر C++
- Clang+LLVM 16 از پیش ساخته شده است

بارهای کاری Java Spring

remotejdk_17 Bazel برای ارائه یک جاوا هرمتیک برای کامپایل استفاده می شود. سایر وابستگی های جاوا در فایل WORKSPACE مدیریت و تعریف می شوند.

بارهای کاری Java Spring در یک فایل jar به نام <service>_application.jar کامپایل می شوند. شیشه حاوی:

فایل های کلاس جاوا
META-INF/
- داده های مانیفست بازل
build-data.properties
- داده های ساخت Bazel
BOOT-INF/
- وابستگی‌های jar بسته‌بندی شده، ایجاد شده توسط rules_spring .

لایه های تصویر

تصویر بار کاری Java Spring از دو لایه تشکیل شده است:

لایه تصویر پایه
- تصویر پایه جاوا: gcr.io/distroless/java17-debian11
لایه بار کاری
- binary_tar.tar
  - <service>_application.jar

پیکربندی تصویر

نقطه ورود
- 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 از چندین لایه تشکیل شده است:

لایه تصویر پایه
- تصویر پایه جاوا: gcr.io/distroless/java17-debian11
لایه های وابستگی بسته دبیان لایه‌ها با استفاده از آرشیوهای deb که از debian-snapshot دانلود شده و به عنوان لایه‌های تصویر دوباره بسته‌بندی می‌شوند، تولید می‌شوند.
- 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
لایه بار کاری
- binary_tar.tar
  - <service>_application.jar
  - libtensorflow-jni.so
  - libaggregation-jni.so

پیکربندی تصویر

برچسب ها (فقط برای تصاویر ساخته شده برای اجرا در TEE)
- "tee.launch_policy.allow_env_override": "FCP_OPTS"
  - به متغیر محیطی FCP_OPTS اجازه می دهد تا در فضای محرمانه تنظیم شود. حجم کار هنگام راه اندازی FCP_OPTS را مصرف می کند تا پارامترهای مورد نیاز را پیکربندی کند.
  - متغیر محیطی FCP_OPTS هنگامی که تصویر اجرا می شود (به جای ساخته شده) تنظیم می شود تا جبر ساخت حفظ شود.
- "tee.launch_policy.log_redirect": "always"
- "tee.launch_policy.monitoring_memory_allow": "always"
نقطه ورود
- java -Djava.library.path=. -jar <service>_application.jar

بارهای کاری پایتون

Bazel's rules_python برای ارائه زنجیره ابزار هرمتیک Python 3.10 استفاده می شود. یک فایل نیازمندی های پیپ قفل شده برای واکشی قطعی وابستگی های پیپ استفاده می شود. تصویر لحظه‌ای دبیان تضمین می‌کند که توزیع‌های قطعی بر اساس سازگاری پلتفرم واکشی می‌شوند و یک زنجیره ابزار C++ برای کامپایل توزیع‌های منبع فراهم می‌کند.

بارهای کاری پایتون در مجموعه ای از بسته های پیپ دانلود شده، توزیع Python 3.10، کد منبع ODP Python و یک اسکریپت راه اندازی پایتون بسته بندی می شود.

<service>.runfiles/
- توزیع پایتون تحت python_x86_64-unknown-linux-gnu/ ذخیره می شود
- کد منبع در com_google_ondevicepersonalization_federatedcompute/ ذخیره می شود
- بسته های Pip در pypi_<dependency_name>/ ذخیره می شوند
<service>.runfiles_manifest
- فایل مانیفست برای دایرکتوری <service>.runfiles/
<service>
- اسکریپت پایتون برای اجرای بار کاری پایتون با استفاده از فایل های اجرا

لایه های تصویر

تصویر بار کاری پایتون از چهار لایه تشکیل شده است:

لایه تصویر پایه
- پایتون تصویر پایه پایتون: باریک
لایه مترجم
- interpreter_layer.jar
  - <service>/<service>.runfiles/python_x86_64-unknown-linux-gnu/**
لایه بسته ها
- packages_layer.jar
  - <service>/<service>.runfiles/**/site-packages/**
لایه بار کاری
- app_tar_manifest.tar
  - حاوی کد منبع، اسکریپت راه‌اندازی و مانیفست است.
    - <service>/<service>.runfiles_manifest
    - <service>/<service>
    - <service>/<service>.runfiles/com_google_ondevicepersonalization_federatedcompute/**

پیکربندی تصویر

نقطه ورود
- /<service>/<service>

ساخت تصاویر

پس از انتخاب بار کاری شما آماده ساخت و انتشار تصاویر خود هستید.

پیش نیازها

Bazel 6.4.0
- به نصب جاوا و C++ نیاز دارد
داکر

رویه

تصاویر باید در ظرف docker ساخته شده توسط dockerfile ارائه شده ساخته شوند. دو اسکریپت برای کمک به ساخت تصاویر قطعی نهایی ارائه شده است.

docker_run.sh
- docker_run.sh تصویر docker را از فایل docker می‌سازد، دایرکتوری کار را سوار می‌کند، شبح داکر میزبان را سوار می‌کند و با دستور bash ارائه شده، docker را اجرا می‌کند. هر متغیری که قبل از دستور bash ارسال شود به عنوان پرچم‌های اجرای docker در نظر گرفته می‌شود.
build_images.sh
- build_images.sh bazel build برای همه تصاویر اجرا می کند و هش تصویر تولید شده را برای هر تصویر ساخته شده خروجی می دهد.

ساخت تمام تصاویر

./scripts/docker/docker_run.sh "./scripts/build_images.sh"

هش تصویر مورد انتظار برای هر نسخه را می توان در نسخه های GitHub محاسباتی odp-federated پیدا کرد.

انتشار تصاویر

انتشار با استفاده از قوانین oci_push Bazel پیکربندی شده است. برای هر سرویس، مخزن هدف باید برای همه پیکربندی شود:

جمع کننده
گردآورنده
model_updater
task_assignment
وظیفه_مدیریت
task_scheduler
task_builder

انتشار یک تصویر واحد

برای انتشار یک تصویر واحد:

./scripts/docker/docker_run.sh "bazel run //shuffler/services/<servicename_no_underscore>:<servicename_with_underscore>_image_publish"

تصاویر ساخته شده

همه تصاویر ساخته شده باید توسط سازنده ذخیره و میزبانی شوند، مانند یک رجیستری مصنوع GCP .

ساخت های قطعی

ساختارهای قطعی از دو جزء اصلی تشکیل شده است:

کامپایل باینری های مورد نیاز این شامل شیشه ها، کتابخانه های مشترک و ابرداده می شود.
وابستگی های تصویر پایه و زمان اجرا. تصویر پایه محیط اجرا که برای اجرای باینری های کامپایل شده استفاده می شود.

در حال حاضر، مخزن محاسبات فدرال ODP از انواع بارهای کاری زیر پشتیبانی می کند:

بارهای کاری جاوا + Spring
- TaskAssignment، TaskManagement، Collector
Java + Spring با بارهای کاری تنسورفلو JNI
- Model Updater، Aggregator
بارهای کاری پایتون
- TaskBuilder

وابستگی ها

فهرست زیر وابستگی هایی است که ODP برای حفظ جبر و در دسترس بودن به آنها تکیه می کند:

بازل
GitHub
ماون
PyPi
عکس های فوری دبیان
رجیستری DockerHub
Google Container Registry (GCR)

بارهای کاری قطعی

عکس های فوری دبیان

سرصفحه ها و کتابخانه های سیستم
معماری سیستم
- linux_x86_64
- دبیان
کامپایلر C++
- Clang+LLVM 16 از پیش ساخته شده است

بارهای کاری Java Spring

بارهای کاری Java Spring در یک فایل jar به نام <service>_application.jar کامپایل می شوند. شیشه حاوی:

فایل های کلاس جاوا
META-INF/
- داده های مانیفست بازل
build-data.properties
- داده های ساخت Bazel
BOOT-INF/
- وابستگی‌های jar بسته‌بندی شده، ایجاد شده توسط rules_spring .

لایه های تصویر

تصویر بار کاری Java Spring از دو لایه تشکیل شده است:

لایه تصویر پایه
- تصویر پایه جاوا: gcr.io/distroless/java17-debian11
لایه بار کاری
- binary_tar.tar
  - <service>_application.jar

پیکربندی تصویر

نقطه ورود
- java -jar <service>_application.jar

بارهای کاری JNI Tensorflow

بارهای کاری JNI در یک کتابخانه مشترک به نام libtensorflow.so همراه با <service>_application.jar کامپایل می شوند.

لایه های تصویر

تصویر بار کاری JNI tensorflow از چندین لایه تشکیل شده است:

لایه تصویر پایه
- تصویر پایه جاوا: gcr.io/distroless/java17-debian11
لایه های وابستگی بسته دبیان لایه‌ها با استفاده از آرشیوهای deb که از debian-snapshot دانلود شده و به عنوان لایه‌های تصویر دوباره بسته‌بندی می‌شوند، تولید می‌شوند.
- 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
لایه بار کاری
- binary_tar.tar
  - <service>_application.jar
  - libtensorflow-jni.so
  - libaggregation-jni.so

پیکربندی تصویر

برچسب ها (فقط برای تصاویر ساخته شده برای اجرا در TEE)
- "tee.launch_policy.allow_env_override": "FCP_OPTS"
  - به متغیر محیطی FCP_OPTS اجازه می دهد تا در فضای محرمانه تنظیم شود. حجم کار هنگام راه اندازی FCP_OPTS را مصرف می کند تا پارامترهای مورد نیاز را پیکربندی کند.
  - متغیر محیطی FCP_OPTS هنگامی که تصویر اجرا می شود (به جای ساخته شده) تنظیم می شود تا جبر ساخت حفظ شود.
- "tee.launch_policy.log_redirect": "always"
- "tee.launch_policy.monitoring_memory_allow": "always"
نقطه ورود
- java -Djava.library.path=. -jar <service>_application.jar

بارهای کاری پایتون

<service>.runfiles/
- توزیع پایتون تحت python_x86_64-unknown-linux-gnu/ ذخیره می شود
- کد منبع در com_google_ondevicepersonalization_federatedcompute/ ذخیره می شود
- بسته های Pip در pypi_<dependency_name>/ ذخیره می شوند
<service>.runfiles_manifest
- فایل مانیفست برای دایرکتوری <service>.runfiles/
<service>
- اسکریپت پایتون برای اجرای بار کاری پایتون با استفاده از فایل های اجرا

لایه های تصویر

تصویر بار کاری پایتون از چهار لایه تشکیل شده است:

لایه تصویر پایه
- تصویر پایه پایتون python:slim
لایه مترجم
- interpreter_layer.jar
  - <service>/<service>.runfiles/python_x86_64-unknown-linux-gnu/**
لایه بسته ها
- packages_layer.jar
  - <service>/<service>.runfiles/**/site-packages/**
لایه بار کاری
- app_tar_manifest.tar
  - حاوی کد منبع، اسکریپت راه‌اندازی و مانیفست است.
    - <service>/<service>.runfiles_manifest
    - <service>/<service>
    - <service>/<service>.runfiles/com_google_ondevicepersonalization_federatedcompute/**

پیکربندی تصویر

نقطه ورود
- /<service>/<service>

ساخت تصاویر

پس از انتخاب بار کاری شما آماده ساخت و انتشار تصاویر خود هستید.

پیش نیازها

Bazel 6.4.0
- به نصب جاوا و C++ نیاز دارد
داکر

رویه

docker_run.sh
- docker_run.sh تصویر docker را از فایل docker می‌سازد، دایرکتوری کار را سوار می‌کند، شبح داکر میزبان را سوار می‌کند و با دستور bash ارائه شده، docker را اجرا می‌کند. هر متغیری که قبل از دستور bash ارسال شود به عنوان پرچم‌های اجرای docker در نظر گرفته می‌شود.
build_images.sh
- build_images.sh bazel build برای همه تصاویر اجرا می کند و هش تصویر تولید شده را برای هر تصویر ساخته شده خروجی می دهد.

ساخت تمام تصاویر

./scripts/docker/docker_run.sh "./scripts/build_images.sh"

هش تصویر مورد انتظار برای هر نسخه را می توان در نسخه های GitHub محاسباتی odp-federated پیدا کرد.

انتشار تصاویر

انتشار با استفاده از قوانین oci_push Bazel پیکربندی شده است. برای هر سرویس، مخزن هدف باید برای همه پیکربندی شود:

جمع کننده
گردآورنده
model_updater
task_assignment
وظیفه_مدیریت
task_scheduler
task_builder

انتشار یک تصویر واحد

برای انتشار یک تصویر واحد:

./scripts/docker/docker_run.sh "bazel run //shuffler/services/<servicename_no_underscore>:<servicename_with_underscore>_image_publish"

تصاویر ساخته شده

همه تصاویر ساخته شده باید توسط سازنده ذخیره و میزبانی شوند، مانند یک رجیستری مصنوع GCP .

ساخت های قطعی

ساختارهای قطعی از دو جزء اصلی تشکیل شده است:

کامپایل باینری های مورد نیاز این شامل شیشه ها، کتابخانه های مشترک و ابرداده می شود.
وابستگی های تصویر پایه و زمان اجرا. تصویر پایه محیط اجرا که برای اجرای باینری های کامپایل شده استفاده می شود.

در حال حاضر، مخزن محاسبات فدرال ODP از انواع بارهای کاری زیر پشتیبانی می کند:

بارهای کاری جاوا + Spring
- TaskAssignment، TaskManagement، Collector
Java + Spring با بارهای کاری تنسورفلو JNI
- Model Updater، Aggregator
بارهای کاری پایتون
- TaskBuilder

وابستگی ها

فهرست زیر وابستگی هایی است که ODP برای حفظ جبر و در دسترس بودن به آنها تکیه می کند:

بازل
GitHub
ماون
PyPi
عکس های فوری دبیان
رجیستری DockerHub
Google Container Registry (GCR)

بارهای کاری قطعی

عکس های فوری دبیان

سرصفحه ها و کتابخانه های سیستم
معماری سیستم
- linux_x86_64
- دبیان
کامپایلر C++
- Clang+LLVM 16 از پیش ساخته شده است

بارهای کاری Java Spring

بارهای کاری Java Spring در یک فایل jar به نام <service>_application.jar کامپایل می شوند. شیشه حاوی:

فایل های کلاس جاوا
META-INF/
- داده های مانیفست بازل
build-data.properties
- داده های ساخت Bazel
BOOT-INF/
- وابستگی‌های jar بسته‌بندی شده، ایجاد شده توسط rules_spring .

لایه های تصویر

تصویر بار کاری Java Spring از دو لایه تشکیل شده است:

لایه تصویر پایه
- تصویر پایه جاوا: gcr.io/distroless/java17-debian11
لایه بار کاری
- binary_tar.tar
  - <service>_application.jar

پیکربندی تصویر

نقطه ورود
- java -jar <service>_application.jar

بارهای کاری JNI Tensorflow

بارهای کاری JNI در یک کتابخانه مشترک به نام libtensorflow.so همراه با <service>_application.jar کامپایل می شوند.

لایه های تصویر

تصویر بار کاری JNI tensorflow از چندین لایه تشکیل شده است:

لایه تصویر پایه
- تصویر پایه جاوا: gcr.io/distroless/java17-debian11
لایه های وابستگی بسته دبیان لایه‌ها با استفاده از آرشیوهای deb که از debian-snapshot دانلود شده و به عنوان لایه‌های تصویر دوباره بسته‌بندی می‌شوند، تولید می‌شوند.
- 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
لایه بار کاری
- binary_tar.tar
  - <service>_application.jar
  - libtensorflow-jni.so
  - libaggregation-jni.so

پیکربندی تصویر

برچسب ها (فقط برای تصاویر ساخته شده برای اجرا در TEE)
- "tee.launch_policy.allow_env_override": "FCP_OPTS"
  - به متغیر محیطی FCP_OPTS اجازه می دهد تا در فضای محرمانه تنظیم شود. حجم کار هنگام راه اندازی FCP_OPTS را مصرف می کند تا پارامترهای مورد نیاز را پیکربندی کند.
  - متغیر محیطی FCP_OPTS هنگامی که تصویر اجرا می شود (به جای ساخته شده) تنظیم می شود تا جبر ساخت حفظ شود.
- "tee.launch_policy.log_redirect": "always"
- "tee.launch_policy.monitoring_memory_allow": "always"
نقطه ورود
- java -Djava.library.path=. -jar <service>_application.jar

بارهای کاری پایتون

<service>.runfiles/
- توزیع پایتون تحت python_x86_64-unknown-linux-gnu/ ذخیره می شود
- کد منبع در com_google_ondevicepersonalization_federatedcompute/ ذخیره می شود
- بسته های Pip در pypi_<dependency_name>/ ذخیره می شوند
<service>.runfiles_manifest
- فایل مانیفست برای دایرکتوری <service>.runfiles/
<service>
- اسکریپت پایتون برای اجرای بار کاری پایتون با استفاده از فایل های اجرا

لایه های تصویر

تصویر بار کاری پایتون از چهار لایه تشکیل شده است:

لایه تصویر پایه
- پایتون تصویر پایه پایتون: باریک
لایه مترجم
- interpreter_layer.jar
  - <service>/<service>.runfiles/python_x86_64-unknown-linux-gnu/**
لایه بسته ها
- packages_layer.jar
  - <service>/<service>.runfiles/**/site-packages/**
لایه بار کاری
- app_tar_manifest.tar
  - حاوی کد منبع، اسکریپت راه‌اندازی و مانیفست است.
    - <service>/<service>.runfiles_manifest
    - <service>/<service>
    - <service>/<service>.runfiles/com_google_ondevicepersonalization_federatedcompute/**

پیکربندی تصویر

نقطه ورود
- /<service>/<service>

ساخت تصاویر

پس از انتخاب بار کاری شما آماده ساخت و انتشار تصاویر خود هستید.

پیش نیازها

Bazel 6.4.0
- به نصب جاوا و C++ نیاز دارد
داکر

رویه

docker_run.sh
- docker_run.sh تصویر docker را از فایل docker می‌سازد، دایرکتوری کار را سوار می‌کند، شبح داکر میزبان را سوار می‌کند و با دستور bash ارائه شده، docker را اجرا می‌کند. هر متغیری که قبل از دستور bash ارسال شود به عنوان پرچم‌های اجرای docker در نظر گرفته می‌شود.
build_images.sh
- build_images.sh bazel build برای همه تصاویر اجرا می کند و هش تصویر تولید شده را برای هر تصویر ساخته شده خروجی می دهد.

ساخت تمام تصاویر

./scripts/docker/docker_run.sh "./scripts/build_images.sh"

هش تصویر مورد انتظار برای هر نسخه را می توان در نسخه های GitHub محاسباتی odp-federated پیدا کرد.

انتشار تصاویر

انتشار با استفاده از قوانین oci_push Bazel پیکربندی شده است. برای هر سرویس، مخزن هدف باید برای همه پیکربندی شود:

جمع کننده
گردآورنده
model_updater
task_assignment
وظیفه_مدیریت
task_scheduler
task_builder

انتشار یک تصویر واحد

برای انتشار یک تصویر واحد:

./scripts/docker/docker_run.sh "bazel run //shuffler/services/<servicename_no_underscore>:<servicename_with_underscore>_image_publish"

تصاویر ساخته شده

همه تصاویر ساخته شده باید توسط سازنده ذخیره و میزبانی شوند، مانند یک رجیستری مصنوع GCP .