إصدار حاسوب موحّد خاص بالتخصيص على الجهاز

يجب توفّر إصدارات خوارزمية محددة للمصادقة على عبء العمل في قسم "على الجهاز". بيئة التنفيذ الموثوقة (TEE) الخاصة بالتخصيص (ODP) متاحة للجميع على Google Cloud كمساحة سرية (CS).

يجب أن تنشئ صور عبء العمل تجزئة صورة حاسمة يمكن استخدامها من خلال علوم الكمبيوتر لمصادقة أعباء العمل (التي تستخدم المصادقة عن بُعد RFC 9334) من المعهد الوطني للمعايير والتكنولوجيا (NIST) بنية الإجراءات (RATS)).

سيستعرض هذا المستند التنفيذ والدعم ينشئ في odp-federatedcompute المستودع. سيتم تشغيل خدمتي "مجمّع ODP" و"أداة تحديث النماذج" ضمن المساحة السرية: ويدعم المستودع الإصدارات الحاسمة لجميع أو الخدمات المطلوبة لحالات استخدام الإنتاج.

البنات شيقة

تتألف التصميمات الحتمية من عنصرين رئيسيين:

  1. تجميع البرامج الثنائية المطلوبة. وهي تشمل الأواني والمكتبات المشتركة وبيانات التعريف.
  2. اعتماديات بيئة التشغيل والصورة الأساسية قاعدة بيئة وقت التشغيل الصورة المستخدمة لتنفيذ البرامج الثنائية التي تم تجميعها.

اعتبارًا من الآن، يدعم مستودع الحوسبة المتحدة ODP الأنواع التالية من أعباء العمل:

  • أعباء العمل في Java والربيع
    • تعيين المهام، وإدارة المهام، والمجمِّع
  • Java + Spring مع أعباء العمل في Tensorflow JNI
    • أداة تحديث النماذج، والعارض
  • أعباء العمل بلغة Python
    • TaskBuilder

التبعيات

القائمة التالية هي تبعيات يعتمد عليها ODP للحفاظ على الحتمية ومدى التوفر:

  • Bazel
  • GitHub
  • Maven
  • PyPi
  • لقطات Debian
  • سجلّ DockerHub
  • Container Registry من Google (GCR)

أعباء العمل التحليلية

ويتم تجميع كل أعباء العمل باستخدام Bazel من خلال سلاسل الأدوات الخاصة بكل لغة وصور الحاويات التي تم إنشاؤها باستخدام rules_oci. مساحة العمل ملف وتحدد جميع التبعيات مع الإصدارات والتجزئات المقابلة.

لقطات Debian

يجب إنشاء جميع صور عبء العمل ضمن dockerfile تستند إلى نبذة عن دبيان. نظام التشغيل Debian لقطات مستودع مستقرة:

أعباء العمل في Java Spring

بازل remotejdk_17 هو لتقديم لغة Java مُحكمة للتجميع. تُعد تبعيات Java الأخرى بشكل عام وتحديد في WorkSPACE .

يتم تجميع أعباء العمل في Java Spring في ملف جرّة يُسمى <service>_application.jar تحتوي البرطمان على ما يلي:

  • ملفات فئة Java
  • META-INF/
    • بيانات بيان Bazel
  • build-data.properties
    • بيانات إنشاء Bazel
  • BOOT-INF/
    • تبعيات الزجاجات المعبأة، التي تم إنشاؤها بواسطة rules_spring.

طبقات الصور

تتكون صورة عبء العمل في Java Spring من طبقتين:

  • طبقة الصورة الأساسية
  • طبقة عبء العمل
    • binary_tar.tar
      • <service>_application.jar

إعدادات الصورة

  • كيفية الوصول إلى "قائمة الفنانين المتعاقدين"
    • java -jar <service>_application.jar

مهام العمل في Tensorflow JNI

يتم إنشاء أعباء عمل JNI Tensorflow وفقًا لأعباء العمل في Java Spring. حاسمة يتم توفير سلسلة أدوات Clang+LLVM Bazel المركّبة باستخدام Clang+LLVM المصممة مسبقًا 16 مع sysroot الذي يوفره صورة لقطة Debian لتجميع التعليمات البرمجية للجهاز.

يتم تجميع أعباء عمل JNI في مكتبة مشتركة تحمل اسم libtensorflow.so جنبًا إلى جنب مع <service>_application.jar.

طبقات الصور

تتكون صورة عبء العمل لـ JNI tensorflow من عدة طبقات:

  • طبقة الصورة الأساسية
  • طبقات تبعية حزمة Debian يتم إنشاء الطبقات باستخدام deb الأرشيفات التي تم تنزيلها من لقطة دبيان وإعادة تجميعها كطبقات صور
    • 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

أعباء العمل بلغة Python

تُستخدم rules_python في بازل من أجل توفير سلسلة أدوات Python 3.10 المُخفية. متطلبات النافذة المقفلة ملف يُستخدم للجلب الحتمي لتبعيات pip. لقطة Debian تضمن الحصول على التوزيعات الحاسمة استنادًا إلى النظام الأساسي التوافق وتوفر سلسلة أدوات C++ لتجميع توزيعات المصدر.

فسيتم حزم أعباء عمل بايثون في مجموعة من حزم pip التي تم تنزيلها، توزيعة Python 3.10 ورمز مصدر ODP Python وشركة Python الناشئة البرنامج النصي.

  • <service>.runfiles/
    • يتم تخزين توزيع بايثون ضمن python_x86_64-unknown-linux-gnu/
    • تم تخزين رمز المصدر ضمن com_google_ondevicepersonalization_federatedcompute/
    • يتم تخزين حِزم "نافذة ضمن النافذة" ضمن "pypi_<dependency_name>/".
  • <service>.runfiles_manifest
    • ملف البيان للدليل <service>.runfiles/
  • <service>
    • نص بايثون لتنفيذ أحمال العمل في بايثون باستخدام ملفات runfiles

طبقات الصور

تتكوّن صورة عبء العمل في لغة بايثون من أربع طبقات:

  • طبقة الصورة الأساسية
  • طبقة الترجمة الفورية
    • 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 التي تم إنشاؤها بواسطة dockerfile. يتم تقديم نصَّين للمساعدة في إنشاء الصور الحتمية النهائية.

  • docker_run.sh
    • سينشئ docker_run.sh صورة Docker من ملف Dockerfile، تثبيت. دليل العمل، وتثبيت البرنامج الخفي لـ Docker، ثم تشغيل Docker باستخدام أمر bash. ستتم إضافة أي متغيرات تم تمريرها قبل الأمر bash التعامل معها على أنها علامات تشغيل Docker.
  • build_images.sh
    • سيُجري build_images.sh تشغيل bazel build لجميع الصور ويُخرج وتجزئات الصور التي تم إنشاؤها لكل صورة تم إنشاؤها.

إنشاء كل الصور

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

ويمكن العثور على تجزئات الصور المتوقعة لكل إصدار ضمن odp-fedeatedcompute 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