‫في الفيديو الأخير ، تناولت الأمر Imperative vs.
‫تصريحي. تحدثنا عن التفاصيل في Kubernetes
‫لأحدهما أو الآخر.
‫حقًا ، عندما تنظر إلى وثائق Kubernetess ، فإنها
‫تفسح المجال لثلاثة أنماط مختلفة.
‫هناك اختلاف طفيف ، لكنهم حقًا في طيف واسع
‫من الضرورة من جانب واحد وكل الطريق تصريحي
‫من ناحية أخرى.
‫ثم هذا الخيار الصغير الجميل في المنتصف إذا
‫اخترت استخدامه. في هذه الدورة التدريبية
‫، حتى الآن ، كنت أعلمك أوامر CLI الصارمة
‫والضرورية. يتضمن الجري وفضح.
‫ربما لدينا مقياس.
‫لم نغطي التعديل ولكنه يفعل بالضبط
‫ما تعتقد أنه سيكون. يقوم بتحرير مورد في الوقت الحقيقي.
‫أو إنشاء النشر ، وهي الطريقة الجديدة للقيام بالتشغيل.
‫هذه حقا أفضل لتعلم كيف
‫تعمل الأشياء. تعلم أنواع الموارد وماذا تفعل ، والمشاريع
‫الشخصية والإعدادات الصغيرة حقًا حيث ربما تكون الشخص
‫الوحيد المسؤول. أنت لا تحاول
‫الأتمتة. أنت لا تحاول إنشاء سير عمل إنتاج
‫كامل ، و CICD ، صحيح.
‫هذا شيء عظيم بالنسبة لهؤلاء.
‫ثم هناك هذه الأرضية الوسطية اللطيفة التي
‫يقدمها لك Kubernetes مع أوامر الإنشاء التي يمكنك إما
‫استخدام أوامر الإنشاء نفسها ، ولكن يمكنك أيضًا استخدام
‫تلك التي تحتوي على ملف YAML.
‫يمكنك استخدام create -f ، ويمكنك إعطائها واحدة
‫من تلك المواصفات كما رأينا سابقًا.
‫يمكنك إعطائها مواصفات ، وستنشئ أيًا من الكائنات الموجودة
‫لديك هناك. يمكن أن يكون لديك كائنات
‫متعددة في هذا الملف. يمكن أن يكون لديك نشر
‫بالإضافة إلى خدمة هناك.
‫ربما تحتاج إلى بعض التخزين لديك ، وإعدادات الشبكات
‫، وما إلى ذلك. يمكن أن يكون لديك كل هذا الملف الجميل.
‫بعد ذلك ، إذا كنت بحاجة إلى استبدال أي شيء
‫هناك ، فيمكنك تحرير الملف ثم استخدام الأمر replace
‫، الذي لم نقم بتغطيته بعد ، ولكنه يفعل ما تعتقد
‫أنه يفعله. ثم ، هناك أمر الحذف ، الذي استخدمناه
‫، والذي يقوم بما تعتقد أنه يفعله أيضًا.
‫الشيء الجميل هنا هو أنه نوع من الوسط ، صحيح.
‫يجبرك على استخدام YAML حتى تكون قد وثقت ما تفعله ،
‫ولديك سجل التغيير هذا إذا كنت تستخدم شيئًا
‫مثل git.
‫نأمل أنك تستخدم git.
‫ومع ذلك ، فإن الفائدة هناك هي بالنسبة لنا
‫نحن البشر ، فنحن نستخدم الإنشاء أو الاستبدال
‫أو الحذف. لذلك ، يعطينا هذا الفعل الصريح
‫لاستخدامه حتى نعرف أننا لا نحذف شيئًا عن طريق الخطأ
‫عندما نستخدم أمر إنشاء.
‫ونحن نعلم أننا لا نحذف شيئًا عن طريق الخطأ عندما
‫نستخدم أمر الاستبدال.
‫لذلك هذا يساعد ، صحيح.
‫هذه أرضية وسطى جيدة حيث تبلل قدميك في مواصفات
‫YAML التي ستحتاج إلى استخدامها عندما تصل
‫إلى نموذج الكائن التوضيحي الكامل.
‫هذا ما كنت أتحدث عنه سابقًا.
‫هذا هو المكان الذي تستخدم فيه YAML فقط وأنت تستخدم الأمر
‫application فقط.
‫هناك أوامر أخرى لمساعدتك في التطبيق ، مثل الفرق ،
‫والتي ستظهر لك التغييرات التي توشك على اتخاذها.
‫ولكن ، تطبيق هو ببساطة تحرير YAML ، تشغيل
‫التطبيق.
‫قم بتحرير المزيد من YAML ، قم بتشغيل التطبيق.
‫هذا مشابه لـ Swarm حيث كان لدينا Swarm stacks.
‫إذا كنت تتذكر ، هناك أمر نشر مكدس عامل ميناء
‫ومن أجل تحديثها ، يمكنك استخدام نفس الأمر مرارًا
‫وتكرارًا.
‫هذا هو نفس النمط هنا مع كائناتهم التوضيحية
‫الكاملة. من الجيد أن لديهم وثائق ،
‫وسترى هذا في روابط الموارد لهذه المحاضرة ،
‫صفحة مفصلة للغاية عن هذه الأنواع الثلاثة المختلفة.
‫أنا أشجعك على التحقق من ذلك.
‫القاعدة الحقيقية التي سأعطيها لهذا
‫الأمر برمته ، حتى لو ذهبت لقراءة صفحة الموارد حول
‫هذا الموضوع ، هي فقط عدم خلط الطرق الثلاثة.
‫من المهم ألا تخلط بين هؤلاء الثلاثة عندما يكون
‫لديك تبعيات إنتاجية حقيقية.
‫في الإنتاج ، سأدافع حقًا عن محاولة
‫الالتزام ، في أقرب وقت ممكن في نموذج النضج
‫الخاص بك ، مع النموذج التصريحي الكامل
‫باستخدام ملفات YAML مع الأمر application.
‫كلما شعرت بالراحة في وقت مبكر ، كلما اعتدت
‫على توثيق ذلك في YAML وحفظه في git-الالتزام
‫في كل مرة تقوم فيها بتغييره ، ستفيدك
‫هذه العملية حقًا لاحقًا.
‫عندما يريد أي شخص رؤية التغييرات التي لديك ، يمكنه
‫الاطلاع على سجل git. ربما يفعل معظمنا شيئًا ما
‫في git اليوم ، لذا فإن إنشاء git repo آخر فقط لتخزين
‫YAMLs لن يكون كثيرًا من الجهد بالنسبة
‫لك ، أليس كذلك. حتى إذا كنت تقوم فقط بتطبيق
‫git محليًا على جهازك ، فيمكن أن يساعدك git محليًا
‫بشكل أساسي في رؤية سجل التغييرات التي أجريتها
‫على YAMLs هذه بحيث يمكنك الانتقال بعد ستة أشهر ما
‫قمت بتغييره قبل ثلاثة أشهر إلى الوراء والنظر وشاهد ما
‫تفعله هناك.
‫هذا سيوفر لك الكثير من الوقت حقًا.
‫أهم قاعدة هي عدم الخلط بين الأساليب.
‫إذا قمت بإنشاء شيء ما باستخدام التشغيل ، فسيكون
‫من الصعب فيما بعد استخدام التطبيق لإدارة هذا المورد.
‫هناك حيل صغيرة في التجارة يمكنك الالتفاف عليها باستخدام
‫بعض هذه الأوامر لمحاولة تعديل العناصر لاحقًا دون
‫إفسادها.
‫ولكن في الحقيقة ، إذا كنت ستقوم بالإنتاج
‫، فمن المحتمل ألا تبدأ بأوامر التشغيل هذه على
‫خادم الإنتاج الخاص بك. ربما يجب أن تفكر على المدى
‫الطويل وتلتزم بـ YAML. تتعلم نصائحي الأربعة
‫هنا سطر الأوامر كما تفعل.
‫تعرف على سطر الأوامر الضروري بحيث يمكنك
‫تشغيله محليًا. وستحتاج أحيانًا إلى هذه الأوامر
‫لاستكشاف الأخطاء وإصلاحها والاختبار والخوادم أيضًا.
‫ثم بأسرع ما يمكن للاستعداد لإنتاجك الأول ، فإن
‫Kubernetes هو معرفة أمر التطبيق ، والأمر diff
‫، ومواصفات YAML لجميع أنواع
‫الموارد التي ستستخدمها.
‫ثم تخزينها في git كما أقول.
‫حتى لو كان الأمر عبارة عن git أو git repos محلية في مكان ما يمكن
‫لفريقك استخدامه.
‫تذكر أن طريقة تحرير YAML هذه ، وحفظ
‫التغيير في git ، ثم تطبيقه باستخدام kubectl
‫، يتم تطبيقها ، ثم حفظها مرة أخرى ، وتخزين التغييرات
‫في git.
‫ستقودك هذه العملية إلى طريق أتمتة DevOps وإلى
‫عمليات git-op التي ذكرتها سابقًا ، والتي
‫أعتقد أن بعض هذه الأدوات بدأت في الانتقال
‫إليها. حيث نحن Git centric.
‫نحن نجري تغييرات في git repo مثلما يفعل مبرمجو
‫البرامج ..
‫نحن نفعل الشيء نفسه مع سير عمل DevOps هذا.
‫نحن نتبنى نوعًا ما الطريقة التي يقومون بها
‫بعمل التغيير في فريق لعملياتنا وأدواتنا.