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

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

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

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

ساخت‌های قطعی

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

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

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

• حجم کار جاوا + اسپرینگ
  • تخصیص وظیفه، مدیریت وظیفه، گردآورنده
• جاوا + اسپرینگ با حجم کاری تنسورفلو JNI
  • به‌روزرسانی‌کننده مدل، تجمیع‌کننده
• حجم کار پایتون
  • وظیفه‌ساز

وابستگی‌ها

لیست زیر وابستگی‌هایی است که ODP برای حفظ قطعیت و در دسترس بودن به آنها متکی است:

• بازل
• گیت‌هاب
• ماون
• پای‌پای
• اسنپ‌شات‌های دبیان
• رجیستری داکرهاب
• رجیستری کانتینر گوگل (GCR)

حجم کار قطعی

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

اسنپ‌شات‌های دبیان

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

• هدرها و کتابخانه‌های سیستم
• معماری سیستم
  • لینوکس_x86_64
  • دبیان
• کامپایلر سی++
  • Clang+LLVM 16 از پیش ساخته شده

حجم کار جاوا اسپرینگ

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

بارهای کاری Java Spring در یک فایل jar با نام <service>_application.jar کامپایل می‌شوند. این 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 که توسط تصویر snapshot دبیان برای کامپایل کد ماشین ارائه شده است، ارائه می‌شود.

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

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

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

• لایه تصویر پایه
  • تصویر پایه جاوا: 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

حجم کار پایتون

rules_python بازل برای ارائه یک زنجیره ابزار پایتون ۳.۱۰ یکپارچه استفاده می‌شود. یک فایل قفل‌شده از الزامات pip برای واکشی قطعی وابستگی‌های pip استفاده می‌شود. تصویر snapshot دبیان تضمین می‌کند که توزیع‌های قطعی بر اساس سازگاری پلتفرم واکشی می‌شوند و یک زنجیره ابزار C++ برای کامپایل توزیع‌های منبع فراهم می‌کند.

بارهای کاری پایتون در مجموعه‌ای از بسته‌های pip دانلود شده، یک توزیع پایتون ۳.۱۰، کد منبع پایتون ODP و یک اسکریپت راه‌اندازی پایتون بسته‌بندی خواهند شد.

• <service>.runfiles/
  • توزیع پایتون در مسیر python_x86_64-unknown-linux-gnu/ ذخیره می‌شود.
  • کد منبع در مسیر com_google_ondevicepersonalization_federatedcompute/ ذخیره می‌شود.
  • بسته‌های پیپ در مسیر 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>

ساخت تصاویر

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

پیش‌نیازها

• بازل ۶.۴.۰
  • نیاز به نصب جاوا و سی پلاس پلاس دارد
• داکر

رویه

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

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

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

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

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

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

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

• جمع کننده
• گردآورنده
• به‌روزرسانی مدل
• وظیفه_تکلیف
• مدیریت_وظایف
• زمانبند وظیفه
• task_builder

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

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

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

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

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