ما هو بوتلر روكيت وكيفية استخدامه في EKS؟

إذا كنت في خضم عملية امتثال أو تحاول بدء رحلتها الصعبة، فقد تجد الكثير من التنبيهات الحمراء بخصوص مثيلات EC2 التي تقوم بتشغيلها. علاوة على ذلك، قد تبدأ في التساؤل عن مدى ملاءمة صور Amazon Linux الافتراضية لحالة استخدامك. قد تتساءل عما إذا كانت هناك صور AMI مخصصة تدعم أعباء عملك المعتمدة على الحاويات، وتتطلب جهدًا أقل للتصحيح وتوفر أمانًا أفضل.

Bottlerocket هو نظام تشغيل مبني خصيصًا يعتمد على Linux، تم تصميمه بدقة ليكون مضيفًا مثاليًا للحاويات. صُمم لتقليل الأعباء غير الضرورية، ويبرز Bottlerocket كحل خفيف وفعال مصمم خصيصًا لتلبية المتطلبات الحديثة للتطبيقات المعتمدة على الحاويات.

💡

تم تصميم صورة Linux المتخصصة هذه مع التركيز بشكل أساسي على تبسيط تنسيق الحاويات مع إعطاء الأولوية للأمان والامتثال والكفاءة التشغيلية.

القيم الأساسية لـ Bottlerocket

يعتمد Bottlerocket على ثلاث قيم أساسية رئيسية مفصلة أدناه

التقليلية

لماذا نحتاج إلى مئات التطبيقات غير المرغوب فيها بينما كل ما أرغب في تشغيله هو صورة Docker؟ يتبنى Bottlerocket نهجًا تقليليًا ليتضمن فقط الحزم الضرورية في صورته الأساسية، مما يجعله خفيفًا وأسهل في الإدارة.

يتم تثبيت جميع الحزم المطلوبة في صورة Linux واحدة وهي مزيج من خدمات AWS المختلفة بالإضافة إلى المنصات/البنى المختلفة التي يدعمها. يُطلق على كل مجموعة اسم متغير.

على سبيل المثال bottlerocket-aws-k8s-1.28-x86_64-1.16 هو متغير لصورة Bottlerocket لإصدار EKS 1.28 على x86_64 معمارية. متغير آخر لـ ECS سيكون شيئًا مثل bottlerocket-aws-ecs-2-x86_64-1.16

تحديثات آمنة

يعتمد Bottlerocket بشكل أساسي على مفهوم تجميع كل شيء في صورة AMI واحدة، وبالتالي لا يوجد مدير حزم.

بما أن كل شيء مرتبط بصورة، لتحديث أي شيء، ما عليك سوى تحديث إصدار الصورة الذي سيحتوي على أحدث إصدار (مستقر وآمن) من جميع المكونات التي تم اختبارها، مما يلغي الحاجة إلى إدارة الحزم بشكل منفصل.

يعرض الجانب الأيسر المثيل قيد التشغيل حيث يتوفر تحديث إصدار أحدث للإصدار الحالي. يتم تنزيل هذا التحديث إلى نفس المثيل ولكن في موقع منفصل. بمجرد اكتمال التنزيل، تتم إعادة التشغيل، مما يجعل الإصدار الجديد هو المصدر الأساسي للنواة.

الأمان

الأمان هو الشغل الشاغل لمثيلات Bottlerocket، وهم يتخذون عدة إجراءات لضمان ذلك

1. نظام الملفات الجذر غير قابل للتغيير — بما أن نظام الملفات الجذر يصبح غير قابل للتغيير، فإن الإصدارات المستقرة والمختبرة فقط هي جزء من صورة المثيل. dm-verity يُستخدم لضمان الشفافية في فحص سلامة نظام الملفات جنبًا إلى جنب مع تجزئة جذر باستخدام شجرةميركل.
2. يتم فرض SeLinux بشكل افتراضي
3. لا يوجد واجهة سطر أوامر (Shell) — وبالتالي تقل فرصة الهجمات عن بعد.

المفاهيم

فيما يلي بعض المفاهيم عالية المستوى لفهم المزيد عن مثيلات Bottlerocket

مدفوع بواجهة برمجة التطبيقات (API)

بما أن مثيلات Bottlerocket لا تحتوي على أي واجهة سطر أوامر (shell)، فكيف يمكنك الاستعلام عن أشياء مثل إصدار الصورة وتحديثاتها، أو العمليات الأساسية، أو مهام مستوى المسؤول؟ لحل هذه المهام، يوفر Bottlerocket واجهة برمجة تطبيقات HTTP محددة جيدًا يمكنها حل جميع هذه المشكلات لك، مع ضمان أن العمليات الصحيحة فقط هي التي يتم إجراؤها على المثيلات بخطوات دقيقة لكل عملية.

حاويات التمهيد

كما ناقشنا سابقًا أن نظام الملفات الجذر غير قابل للتغيير ويتم التحقق منه بواسطة dm-verity ، فإن /etc يصبح جزءًا من نظام الملفات القابل للتغيير الخاص بك باستخدام tmpfs.

باستخدام حاويات التمهيد، يمكنك تمكين برامج أو ميزات معينة ترغب في تثبيتها فوق نظام الملفات الجذر أثناء إقلاع مثيلك. هذه مجموعة من الحاويات التي تعمل فوق بيئة تشغيل الحاويات containerd . يمكنك تشغيل العديد من حاويات التمهيد هذه، وسيكتمل إقلاع المثيل بمجرد خروج جميع الحاويات بنجاح. يمكنك تطبيق شروط خروج معينة على حاويات التمهيد هذه. يمكنك قراءة المزيد حول هذا هنا.

بشكل افتراضي، يتم تمكين التمهيد الآمن أيضًا لضمان تحميل البرنامج الصحيح بواسطة برنامج UEFI الثابت عند محاولة تشغيل الجهاز.

المكونات

مثيلات Bottlerocket مخصصة لأعباء العمل المحتواة، ولهذا الغرض يتم تشغيل مجموعتين من containerd مثيلات تعمل. يتم استخدام إحداها لتشغيل حاوياتك العادية على محرك المنسق الخاص بك مثل kubelet والأخرى لتشغيل حاوية إدارية يمكن أن تعمل كصدفة زائفة (pseudo shell) لتشغيل استدعاءات HTTP التي تعتمد على واجهة برمجة التطبيقات باستخدام apiclient ، وهي أداة يوفرها bottlerocket لتشغيل طلبات API وتصحيح أخطاء مثيلاتك. لا تضمن حاويات الإدارة هذه قابلية التغيير على نظام الملفات الجذر.

استخدام مثيلات Bottlerocket في EKS

يعد استخدام مثيلات bottlerocket في عقد EKS الخاصة بك بسيطًا للغاية. نحتاج فقط إلى التأكد من أننا نمرر AMIs الصحيحة والتسميات الصحيحة إلى العقد حتى يتمكن مشغل تحديث bottlerocket من التحقق فعليًا من تحديثات الصور على هذه العقد وإعادة تشغيلها عند توفر تحديث. سنتناول مشغل تحديث bottlerocket قريبًا.

في نشر EKS الحالي لدينا، نقوم بنشر العقد على شكلين

1. Terraform — الذي يقوم بإنشاء مجموعة العقد الأولية لنا. تُستخدم مجموعة العقد الأولية هذه لتشغيل Karpenter pods والتي تقوم بعد ذلك بإنشاء العقد حسب الحاجة
2. عقد Karpenter — يتم إنشاء هذه العقد بواسطة وحدة تحكم Karpenter كلما كان هناك عبء عمل معلق.

تغييرات Terraform EKS

لإجراء تغييرات في كود Terraform الخاص بـ EKS، نمرر خيارًا eks_managed_node_groups حيث نضيف مجموعة عقد إضافية بهذا الشكل

eks_managed_node_groups = {    
 bottle = {
     enable_bootstrap_user_data = true
     platform = "bottlerocket"
     bootstrap_extra_args = <<-EOT
       [settings]
       "motd" = "TrueFoundry: MLOps platform"
       [settings.kubernetes.node-labels]
       "bottlerocket.aws/updater-interface-version" = "2.0.0"
     EOT

     instance_types = local.env.user_input.tfy_control_plane.enabled == "True" ? ["c6a.xlarge", "m6a.xlarge", "c6i.xlarge", "r6a.xlarge"] : ["c6a.large", "m6a.large", "c6i.large", "r6a.xlarge"]
     capacity_type  = "SPOT"
     ami_type       = "BOTTLEROCKET_x86_64"
     # غير مطلوب ولا مستخدم - تجنب وسم مجموعتي أمان بنفس الوسم أيضًا
     create_security_group = false

     # تأكد من توفر سعة كافية لتشغيل وحدتي Karpenter
     min_size = 2
     max_size = 2
     desired_size = 2

     labels = {
       "class.truefoundry.io" = "bottle"
     }

     tags = {
       # سيقوم هذا بوسم قالب الإطلاق الذي تم إنشاؤه لاستخدامه بواسطة Karpenter
       "karpenter.sh/discovery" = local.env.cluster_name
     }
     block_device_mappings = {
       xvdb = {
         device_name = "/dev/xvdb"
         ebs = {
           volume_size           = 100
           volume_type           = "gp3"
           throughput            = 150
           delete_on_termination = true
         }
       }
     }
   }
 }


In these there are few important things to note in the above spec

1. We need to pass the "bottlerocket.aws/updater-interface-version" = "2.0.0" so that bottlerocket update operator can interface it.
2. ami_type = "BOTTLEROCKET_X86_64" — to pass the bottlerocket AMI
3. block device mapping to /dev/xvdb — bottlerocket can’t use /dev/xvda as custom AMI is using /dev/xvda to store the root image of size 2GB.

Karpenter

Karpenter is relatively newer way of autoscaling your workloads. Based on the compute required it will try to bring the right sized node, simultaneously bin-packing the daemonsets so that all necessary workloads gets executed on the node.

We rely heavily on karpenter to spin Compute and GPU workloads. Karpenter has a concept called Provisioner(which is now deprecated and named as NodePool ) defining the allowed size of nodes with right labels and taints if required. Moreover through AwsNodeTemplates (which is now deprecated and named as NodeClasses ) you can define the template of the node, giving the right security group, AMI family and root volume size.

Now you can understand where we might have to make changes in the Karpenter provisioner and awsnodetemplates to make sure Karpenter spins Bottlerocket instances.

1. We give the label "bottlerocket.aws/updater-interface-version" = "2.0.0" in the provisioner section.
2. We give the root volume to be /dev/xvdb and amiFamily as Bottlerocket in awsnodetemplate

Through this Karpenter is able to support bottlerocket instances as well.

I am trying to avoid mentioning the provisioner and awsnodetemplate spec as they are now deprecated by karpenter in older versions.

Bottlerocket Update operator (brupop)

Bottlerocket update operator or brupop is a controller for keeping your bottlerocket instances in an EKS cluster up-to-date.

Brupop design

It consists of three main components

1. Controller — Controller is the main brain which checks for upstream image updates and orchestrates the entire update process
2. Agent — Agent runs on each node which gets instructions by controller to perform the operation
3. API server — API which authenticates the agent and the API calls its trying to make

Installing brupop

Brupop has two helm charts which we need to install

• bottlerocket-shadow — which consists of bottlerocketshadow CRDs

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
 name: bottlerocket-shadow
 namespace: argocd
 finalizers:
 - resources-finalizer.argocd.argoproj.io
spec:
 destination:
   namespace: brupop-bottlerocket-aws
   server: https://kubernetes.default.svc
 project: default
 source:
   chart: bottlerocket-shadow
   repoURL: https://bottlerocket-os.github.io/bottlerocket-update-operator
   targetRevision: 1.0.0
 syncPolicy:
   automated: {}
   syncOptions:
     - CreateNamespace=true

• bottlerocket-update-operator — والذي يتكون من المشغل الفعلي

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
 name: bottlerocket-update-operator
 namespace: argocd
 finalizers:
 - resources-finalizer.argocd.argoproj.io
spec:
 destination:
   namespace: brupop-bottlerocket-aws
   server: https://kubernetes.default.svc
 project: default
 source:
   chart: bottlerocket-update-operator
   repoURL: https://bottlerocket-os.github.io/bottlerocket-update-operator
   targetRevision: 1.3.0
 syncPolicy:
   automated: {}
   syncOptions:
     - CreateNamespace=true
   

تأكد من أن مساحة الاسم الوجهة هي دائمًا brupop-bottlerocket-aws لأنه ثابت في مخطط Helm الخاص بهم.

تستخدم وحدة التحكم الـ bottlerocketshadow CRDS لإدارة العقد الخاصة بك. في وقت سابق من الوثيقة، طلبنا من العقد أن تحتوي على تسميات "bottlerocket.aws/updater-interface-version" = "2.0.0" . تم ذلك لكي تتمكن وحدة التحكم من تحديد أي من مثيلات Bottlerocket تريد أن يتحكم brupop فيها نيابة عنك.

يمكنك ببساطة التحقق من حالة العقد الخاصة بك عن طريق تشغيل

$ kubectl get brs  -n brupop-bottlerocket-aws
الاسم                               الحالة   الإصدار   الحالة المستهدفة   الإصدار المستهدف   عدد الأعطال
brs-ip-xx-xx-1-243.ec2.internal    خامل    1.17.0    خامل           لا توجد قيمة       0
brs-ip-xx-xx-14-136.ec2.internal   خامل    1.17.0    خامل           لا توجد قيمة       0
brs-ip-xx-xx-31-78.ec2.internal    خامل    1.17.0    خامل           لا توجد قيمة       0


دعم Bottlerocket لـ TrueFoundry

نحن في TrueFoundry دعم مثيلات بوتلر روكيت لدعم أعباء عمل وحدة المعالجة المركزية (CPU) ووحدة معالجة الرسوميات (GPU) على حد سواء، بحيث يمكن الآن تركيز رحلة MLOps بأكملها على تطوير الكود الصحيح لحل المشكلات الصحيحة، مما يقلل الضغط على التصحيحات القابلة للصيانة وإصلاحات الأمان.

الأسئلة الشائعة

ما هو بوتلر روكيت؟

بوتلر روكيت هو نظام تشغيل مبني على لينكس ومصمم خصيصًا ليكون مضيفًا مثاليًا للحاويات. يقلل من النفقات العامة للتطبيقات المعبأة في حاويات بفضل كفاءته وخفته. يبسط نظام التشغيل المتخصص هذا تنسيق الحاويات في EKS، مع إعطاء الأولوية للأمان القوي والامتثال والكفاءة التشغيلية لأعباء العمل الحديثة.

لماذا نستخدم بوتلر روكيت؟

استخدم **بوتلر روكيت** لتصميمه البسيط والمخصص، والمُحسّن لأعباء عمل الحاويات. يعزز الأمان بفضل نظام ملفات الجذر غير القابل للتغيير ويوفر تحديثات مبسطة قائمة على الصور، مما يلغي الحاجة إلى إدارة الحزم المعقدة. يعزز نظام التشغيل المتخصص هذا الكفاءة التشغيلية والامتثال، مما يجعله مثاليًا لمجموعات EKS.

هل يستخدم وضع EKS التلقائي بوتلر روكيت؟

يمكن لأدوات التحجيم التلقائي في EKS مثل Karpenter الاستفادة من بوتلر روكيت بالفعل. يمكنك تكوين Karpenter لتوفير العقد باستخدام صور AMI الخاصة ببوتلر روكيت، مما يوفر مضيفًا آمنًا وبسيطًا وفعالًا لتطبيقاتك المعبأة في حاويات. يضمن هذا التكامل عمليات مبسطة وأمانًا معززًا لأعباء عمل EKS الديناميكية لديك.

ما هو بوتلر روكيت AMI؟

صورة AMI الخاصة ببوتلر روكيت هي صورة آلة أمازون (Amazon Machine Image) مهيأة مسبقًا بنظام التشغيل بوتلر روكيت. هذه الصورة المتخصصة لنظام لينكس هي مضيف حاويات آمن وبسيط مصمم لتطبيقات الحاويات الحديثة. تبسط الإدارة وتضمن تحديثات آمنة عن طريق تجميع جميع المكونات في صورة واحدة، مما يجعلها مثالية لبيئات EKS في الولايات المتحدة.

هل بوتلر روكيت غير قابل للتغيير؟

نعم، نظام ملفات الجذر لمثيل بوتلر روكيت غير قابل للتغيير. تضمن ميزة الأمان الحاسمة هذه أن تكون الإصدارات المستقرة والمختبرة فقط جزءًا من الصورة، مما يعزز السلامة. تتم التحديثات عن طريق استبدال صورة بوتلر روكيت بأكملها، مما يبسط الإدارة ويعزز الأمان لبيئات EKS الخاصة بك.

ما هو بوتلر روكيت في EKS؟

بوتلر روكيت هو نظام تشغيل لينكس مصمم خصيصًا ومُحسّن لأعباء عمل الحاويات على Amazon EKS. يوفر أساسًا بسيطًا وآمنًا وفعالًا لعقد EKS الخاصة بك، مما يقلل من النفقات التشغيلية ويعزز الوضع الأمني. يبسط نظام التشغيل المتخصص هذا تنسيق الحاويات، مما يجعل بيئة بوتلر روكيت EKS الخاصة بك أكثر موثوقية.

ما هو نظام التشغيل بوتلر روكيت؟

نظام التشغيل بوتلر روكيت هو نظام تشغيل مبني على لينكس ومصمم خصيصًا ليكون مضيفًا مثاليًا للحاويات. تم تصميمه لتحقيق أقصى قدر من الكفاءة والأمان والامتثال. يوفر نظام التشغيل المتخصص هذا نهجًا بسيطًا، مما يبسط تنسيق الحاويات ويسهل إدارتها للتطبيقات المعبأة في حاويات، خاصة في بيئات مثل EKS، عن طريق تقليل النفقات العامة غير الضرورية.