डिवाइस पर मौजूद वर्कलोड को प्रमाणित करने के लिए, तय किए गए बिल्ड ज़रूरी हैं पर्सनलाइज़ेशन (ओडीपी) ट्रस्टेड एक्ज़ीक्यूशन एनवायरमेंट (टीईई), सार्वजनिक तौर पर उपलब्ध गोपनीय स्पेस (सीएस) के तौर पर Google Cloud.
वर्कलोड इमेज को एक डिटरमिनिस्टिक इमेज हैश जनरेट करना होगा. इसका इस्तेमाल ये काम कर सकेंगे वर्कलोड के प्रमाणित करने के लिए CS (जो एनआईएसटी के आरएफ़सी 9334 रिमोट एटेस्टेशन का इस्तेमाल करता है) प्रोसेसएस (आरएटीएस) आर्किटेक्चर).
इस दस्तावेज़ में लागू करने से जुड़े डेटा और डेटरमिनिस्टिक के बारे में बताया गया है में बनता है odp-federatedcompute डेटा स्टोर करने की जगह. ओडीपी एग्रीगेटर और मॉडल अपडेटर सेवाएं इसके अंदर चलेंगी गोपनीय स्पेस. यह रिपॉज़िटरी, हमारे सभी उपयोगकर्ताओं के लिए डेटरमिनिस्टिक बिल्ड में मदद करता है किसी प्रॉडक्ट के लिए ज़रूरी है.
कंप्यूटिस्टिक बिल्ड
डिटरमिनिस्टिक बिल्ड में दो मुख्य कॉम्पोनेंट होते हैं:
- ज़रूरी बाइनरी का कंपाइलेशन. इसमें जार, शेयर की गई लाइब्रेरी, और मेटाडेटा.
- बेस इमेज और रनटाइम डिपेंडेंसी. रनटाइम एनवायरमेंट का बेस कंपाइल की गई बाइनरी को लागू करने के लिए इस्तेमाल की जाने वाली इमेज.
फ़िलहाल, ओडीपी फ़ेडरेटेड कंप्यूट रिपॉज़िटरी का इस्तेमाल इन तरीकों से किया जा सकता है: वर्कलोड:
- Java और स्प्रिंग वर्कलोड
- टास्क असाइनमेंट, टास्क मैनेजमेंट, कलेक्टर
- JNI tensorflow वर्कलोड के साथ Java + Spring
- ModelUpdater, एग्रीगेटर
- Python वर्कलोड
- TaskBuilder
डिपेंडेंसी
नीचे दी गई सूची उन डिपेंडेंसी पर निर्भर करती है जिनका इस्तेमाल ओडीपी, डिटरमिनिज़्म को बनाए रखने के लिए करता है और उपलब्धता:
- Bazel
- GitHub
- Maven
- PyPi
- Debian स्नैपशॉट
- DockerHub रजिस्ट्री
- Google कंटेनर रजिस्ट्री (GCR)
तय किए गए वर्कलोड
सभी वर्कलोड को Basel के साथ कंपाइल किया जाता है भाषा-विशिष्ट टूलचेन और कंटेनर इमेज का इस्तेमाल करके बनाई गई हैं rules_oci. वर्कस्पेस फ़ाइल सभी डिपेंडेंसी को उनसे जुड़े वर्शन और हैश के साथ तय करता है.
Debian स्नैपशॉट
वर्कलोड वाली सभी इमेज, दी गई ऐसेट में ही बनाई जानी चाहिए dockerfile डेबियन स्नैपशॉट के ऊपर बनाई गई है. डेबियन स्नैपशॉट, डेटरमिनिस्टिक के साथ स्टेबल रिपॉज़िटरी स्नैपशॉट देते हैं:
- सिस्टम हेडर और लाइब्रेरी
- सिस्टम आर्किटेक्चर
- linux_x86_64
- डेबियन
- C++ कंपाइलर
Java Spring वर्कलोड
बेज़ल
remotejdk_17
है
जिसका इस्तेमाल कंपाइलेशन के लिए हर्मेटिक Java उपलब्ध कराने के लिए किया जाता था. अन्य Java डिपेंडेंसी हैं
वर्कस्पेस में मैनेज और तय किए गए हैं
फ़ाइल में सेव किया जाता है.
Java स्प्रिंग वर्कलोड, नाम की एक जार फ़ाइल में कंपाइल किए जाते हैं
<service>_application.jar
. जार में ये चीज़ें शामिल होती हैं:
- Java क्लास फ़ाइलें
META-INF/
- बेज़ल मेनिफ़ेस्ट डेटा
build-data.properties
- Baज़र का बिल्ड-डेटा
BOOT-INF/
- पैकेज की गई जार डिपेंडेंसी, इनसे जनरेट होती है rules_spring का तरीका.
इमेज लेयर
Java स्प्रिंग वर्कलोड इमेज की दो लेयर होती हैं:
- बेस इमेज लेयर
- Java बेस इमेज:
gcr.io/distroless/java17-debian11
- Java बेस इमेज:
- वर्कलोड लेयर
binary_tar.tar
<service>_application.jar
इमेज कॉन्फ़िगरेशन
- ऐक्सेस का तरीका
java -jar <service>_application.jar
JNI Tensorflow वर्कलोड
JNI Tensorflow वर्कलोड, Java Spring वर्कलोड के ऊपर बनाए जाते हैं. ऐप्लिकेशन हर्मेटिक Clang+LLVM बज़ल टूलचेन, पहले से बने Clang+LLVM फ़ंक्शन का इस्तेमाल करके उपलब्ध कराई गई है 16 मशीन कोड को कंपाइल करने के लिए, Debian स्नैपशॉट इमेज से लिया गया sysroot.
JNI वर्कलोड, libtensorflow.so
नाम की शेयर की गई लाइब्रेरी में कंपाइल किए जाते हैं
<service>_application.jar
के साथ.
इमेज लेयर
JNI tensorflow वर्कलोड इमेज में कई लेयर होती हैं:
- बेस इमेज लेयर
- Java बेस इमेज:
gcr.io/distroless/java17-debian11
- Java बेस इमेज:
- 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 टूलचेन उपलब्ध कराएं. पीआईपी को लॉक करने के लिए ज़रूरी शर्तें फ़ाइल का इस्तेमाल पीआईपी डिपेंडेंसी की डिटरमिनिस्टिक फ़ेचिंग के लिए किया जाता है. Debian स्नैपशॉट इमेज से यह पक्का होता है कि प्लैटफ़ॉर्म के हिसाब से डिटरमिनिस्टिक डिस्ट्रिब्यूशन को फ़ेच किया गया है साथ काम करता है या नहीं और सोर्स डिस्ट्रिब्यूशन को कंपाइल करने के लिए, C++ टूलचेन उपलब्ध कराता है.
Python वर्कलोड को डाउनलोड किए गए पीआईपी पैकेज के सेट में पैकेज किया जाएगा, Python 3.10 डिस्ट्रिब्यूशन, ODP Python सोर्स कोड, और Python स्टार्टअप स्क्रिप्ट.
<service>.runfiles/
- Python डिस्ट्रिब्यूशन को
python_x86_64-unknown-linux-gnu/
में सेव किया जाता है - सोर्स कोड इसके तहत सेव किया जाता है
com_google_ondevicepersonalization_federatedcompute/
- पीआईपी पैकेज,
pypi_<dependency_name>/
में सेव किए जाते हैं
- Python डिस्ट्रिब्यूशन को
<service>.runfiles_manifest
<service>.runfiles/
डायरेक्ट्री के लिए मेनिफ़ेस्ट फ़ाइल
<service>
- रनफ़ाइल का इस्तेमाल करके Python वर्कलोड चलाने के लिए Python स्क्रिप्ट
इमेज लेयर
Python वर्कलोड इमेज में चार लेयर होती हैं:
- बेस इमेज लेयर
- Python बेस इमेज 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>
इमेज बनाएं
जब आपका वर्कलोड चुन लिया जाए, तो आप अपना वर्कलोड तैयार और पब्लिश करने के लिए तैयार हैं इमेज.
ज़रूरी शर्तें
काम का तरीका
इमेज, दिए गए डॉकर कंटेनर में बनाई जानी चाहिए dockerfile पर उपलब्ध है. आखिरी सारणिक इमेज बनाने में मदद के लिए दो स्क्रिप्ट दी गई हैं.
- docker_run.sh
docker_run.sh
, Dockerfile से डॉकर इमेज बनाएगा, वर्क डायरेक्ट्री में, होस्ट डॉकर डीमन को माउंट करें और Docker को बैश कमांड दिया गया है. बैश कमांड से पहले पास किए गए सभी वैरिएबल को डॉकर रन फ़्लैग माना जाएगा.
- build_images.sh
build_images.sh
सभी इमेज के लिएbazel build
चलाएगा और आउटपुट हर बिल्ट इमेज के लिए जनरेट किए गए इमेज हैश.
सभी इमेज बनाएं
./scripts/docker/docker_run.sh "./scripts/build_images.sh"
हर रिलीज़ के लिए अनुमानित इमेज हैश odp-फ़ेडरेटेड GitHub रिलीज़ के बारे में ज़्यादा जानें.
इमेज पब्लिश करें
प्रकाशन को इसका इस्तेमाल करके कॉन्फ़िगर किया गया है oci_push बेज़ल के नियम. हर सेवा के लिए, टारगेट रिपॉज़िटरी को कॉन्फ़िगर किया जाना चाहिए सभी:
- एग्रीगेटर
- कलेक्टर
- 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 आर्टफ़ैक्ट रजिस्ट्री.