توضح هذه المقالة القدرة / الفكرة / مفهوم تغيير الإعدادات العامة على خوادم الأوامر المحلية في بنية أساسية كبيرة باستخدام Gitlab CI و Ansible.
لنفترض أن لديك 20 فريق تطوير وفريق إدارة / DevOps. كيفية تغيير كلمات مرور المسؤول على جميع الخوادم؟ كيفية إضافة شهادة الجذر Enterprise إلى كافة الخوادم؟ الخ.
ما المشكلة التي تحلها؟
الوضع النموذجي:
هناك مسؤولون عالميون / DevOps.
هناك إعدادات عامة (NTP ، DNS ، وكيل ، إلخ.)
هناك فرق تطوير محلية: TeamA ، TeamB ، TeamC ، TeamD ، إلخ.
هناك مطورون يمكنهم فقط الانتقال إلى خوادم فريقهم.
كيفية إضافة / تحديث المسؤولين العالميين ، الإعدادات العالمية؟
المهمة معقدة بسبب حقيقة أن الإعدادات العامة يتم تخزينها بشكل منفصل عن إعدادات الأوامر المحلية في المستودعات الخاصة.
إذا كان لديك عدد قليل من الخوادم في الشركة بأكملها ، فيمكنك بدء تشغيل Ansible في وضع بسيط - بدء تحديث المسؤولين العالميين والإعدادات العالمية على جميع الخوادم في وقت واحد.
بالنسبة للمنشآت الكبيرة ، تستخدم الشركات عادةً العرائس والشيف.
مفهوم
لتغيير الإعدادات العامة على خوادم الأوامر المحلية في بنية أساسية كبيرة ، أقترح آلية وحدة فرعية git.
يستخدم المستودع ذو الإعدادات المحلية وحدات git الفرعية ذات الإعدادات العامة.
يوجد أدناه مخطط تخطيطي لربط مستودع تخزين خاص بالإعدادات العامة لمستودعات الأمر المحلية.
يمكنك استخدام مفهوم تحديث الإعدادات العامة باستخدام الوحدة الفرعية git في البنية التحتية مع Puppet، Chef، Salt ، لكن المقالة تقدم مثالاً مع Ansible.
على سبيل المثال ، قم بتثبيت tomcat و mysql و nginx وتطبيق الإعدادات العامة عليها في فريق يسمى team.
هناك مجموعة شائعة في gitlab تحتوي على الإعدادات العامة.
في المجموعة المشتركة ، يوجد مشروع تمهيد أساسي يحتوي على مسؤولين ، وإعدادات sysctl ، إلخ.
عادة ما يكون هناك العديد من إدارات التطوير في الشركة - وغالبًا ما تسمى الفرق.
في gitlab ، قم بإنشاء مجموعة فريق (سيكون لديك اسم فريقك الخاص).
في مجموعة الفريق نخلق مشاريع: التطبيق ، قاعدة البيانات ، loadbalancer.
لقطة شاشة من قاعدة bootstrap والتطبيق وقاعدة البيانات و loadbalancer:
يتم تضمين مستودع قاعدة bootstrap بمثابة وحدة فرعية git في التطبيق ، قاعدة البيانات ، مستودع loadbalancer.
في كل مرة يبدأ التطبيق وقاعدة البيانات و loadbalancer في المستودع في تحديث الوحدة الفرعية التمهيد الأساسي.
بعد ذلك ، يتم تطبيق ansible-playbook من base-bootstrap و ansible-playbook من base-bootstrap على خوادم التطبيق وقواعد البيانات و loadbalancer.
أي إذا قمت بإضافة مسؤول جديد إلى base-bootstrap أو قمت بتغيير إعدادات النظام في base-bootstrap ، ثم مع التطبيق وقاعدة البيانات و loadbalancer ، يتم تطبيق الإعدادات الجديدة من base-bootstrap على التطبيق وقاعدة البيانات و loadbalancer.
التحضير
يجب عليك قراءة مقالات حول Ansible للمبتدئين:
# Ansible من أين نبدأ
# دليل Ansible
يجب أن يكون لديك gitlab و gitlab-runner مع تثبيت عامل ميناء.
يستخدم منفّذ عامل الميناء كمثال هنا - يمكنك استخدام مُنفّذ Shell.
كيفية نشر gitlab و gitlab-runner:
# ساوثبريدج غيتلاب- CI المادة
# التكامل المستمر ونشر Docker في GitLab CI
يجب أن يكون لديك 3 خوادم (على سبيل المثال ، على ubuntu): التطبيق ، قاعدة البيانات ، loadbalancer.
التطبيق ، قاعدة البيانات ، loadbalancer هي الأسماء الشائعة.
يمكن توسيع جميع الأمثلة وتحسينها واستخدامها بواسطة برامج أخرى - توضح المقالة المبدأ العام.
كيفية التنفيذ
يمكن الحصول على مستودعات وكل رمز الاختبار من هنا: https://github.com/patsevanton/ansible-gitlab-habr
إذا ذهبت إلى الخادم باستخدام اسم المستخدم / كلمة المرور ، في المجموعة المرغوبة (في فريق الحالة هذا) ، قم بإنشاء متغير كلمة المرور للمستخدم (عند التغيير ، تحتاج أيضًا إلى تغيير المتغير في الكود أيضًا) وحدد كلمة المرور هناك (يتم استخدام كلمة مرور كلمة المرور في الكود)
لا تنس إنشاء المستخدم الضروري مع حقوق sudo على الخوادم النهائية (يتم استخدام رمز المستخدم في الكود).
بالنسبة لأولئك الذين يذهبون إلى الخادم باستخدام مفاتيح SSH ، تحتاج إلى إنشاء متغير SSH_PRIVATE_KEY في مجموعة الفريق وإضافة المفتاح الخاص للمستخدم إليه الذي سيتم الاتصال بالخادم.
هذا مثال بسيط على الاتصال بالخوادم ، لذلك لا تتم تغطية مشكلات الأمان في هذه المقالة.
في كل مستودع (تطبيق ، قاعدة بيانات ، loadbalancer) ، أنشئ وحدة فرعية من بوابة:
git submodule add git@gitlab.example.com:common/base-bootstrap.git git submodule add git@gitlab.example.com:team/team-users.git
هناك حاجة إلى وحدة فرعية للوصول إلى المستودع الخاص المشترك.
في حالتنا ، هذا هو المستودع الذي يحتوي على الإعدادات العامة لقاعدة boot-bootst ومستودع المستخدم في فريق مستخدمي الفريق.
حيث gitlab.example.com هو خادم gitlab الخاص بك.
ثم في .ititodules نقوم بتغيير المسار إلى المستودع إلى النسبي
مثال:
[submodule "team-users"] path = team-users url = ../team-users.git [submodule "base-bootstrap"] path = base-bootstrap url = ../../common/base-bootstrap.git
في كل مستودع في المضيفين ، نقوم بتغيير عنوان IP الخاص بنا ، في ansible.cfg نغير remote_user إلى مستخدمنا.
إذا لم يكن لديك أي تعهدات خلال الساعات / الأيام القليلة الماضية ، وكنت بحاجة إلى طرح تغييرات عامة جديدة على الخوادم (على سبيل المثال ، تحتاج إلى إضافة مسؤول جديد) - بالنسبة لمثل هذه المواقف ، يكون هناك سحب واضح.
قم بإعداد السحب المريح لتنزيل مستودع المشترك / قاعدة التمهيد.
للقيام بذلك ، قم بإضافة مستودع نشر الرمز المميز.
انتقل إلى مستودع المشترك / قاعدة التمهيد - ثم انتقل إلى الإعدادات / مستودع / نشر الرموز.
إنشاء رمز. يتم تسجيل اسم المستخدم وكلمة المرور الناتجة في base-bootstrap / vars / cron.yml.
بعد التحقق من أن كل شيء يعمل بشكل صحيح - أعتقد أن الأمر يستحق تغيير وقت بدء السحب غير المرغوب فيه من "كل دقيقتين" إلى الوقت الذي يناسبك.
إذا انخفض السحب الموضح ، فهذا يعني أن CI لهذه الخدمة ستنخفض ، والتي تبدأ في كل مرة تلتزم فيها بمستودع الخدمة (دعنا نقول خدمة تسمى التطبيق)
تحقق
إنشاء مسؤول جديد.
حاول إضافة مسؤول جديد على https://github.com/patsevanton/ansible-gitlab-habr/blob/master/commons/base-bootstrap/vars/users.yml
تغيير Sysctl
حاول إضافة / تغيير إعدادات sysctl في https://github.com/patsevanton/ansible-gitlab-habr/blob/master/commons/base-bootstrap/vars/sysctl.yml
إضافة إدخالات إلى cron
حاول إضافة إدخالات cron إلى https://github.com/patsevanton/ansible-gitlab-habr/blob/master/commons/base-bootstrap/vars/cron.yml
تمديد أو تثبيت التطبيقات الخاصة بك
تحتاج أولاً إلى العثور على دور لتثبيت تطبيقاتك.
انتقل إلى https://galaxy.ansible.com/ وابحث عن دور تثبيت التطبيق الخاص بك.
حاول تثبيت التطبيق الخاص بك باستخدام الدور من وحدة التحكم على الخوادم الخاصة بك. عادةً ما تحتوي جميع الأدوار على إرشادات في الوصف.
على سبيل المثال ، حاول تثبيت java بجانب tomcat. قم أولاً بتثبيت دور geerlingguy.java
ansible-galaxy install geerlingguy.java
قم بإنشاء ansible.cfg القياسي مثل المستودعات.
إنشاء مخزون:
[java] java ansible_host=IP-
إنشاء قواعد اللعبة التي تمارسها java.yml
- hosts: java become: yes vars_files: - vars/main.yml roles: - { role: geerlingguy.java }
قم بتشغيل java.yml ansible-playbook
إذا نجح كل شيء ، أضف إلى المشروع المطلوب (في تطبيق الحالة)
تتم إضافة دور geerlingguy.java إلى بعد دور robertdebock.tomcat https://github.com/patsevanton/ansible-gitlab-habr/blob/master/team/application/tomcat-app.yml#L11
وينطبق الشيء نفسه على جميع التطبيقات الأخرى التي تحتاج إلى تثبيتها على الخادم.
اختبار قواعد اللعبة والأمن
لتبسيط المقالة ، لا يتم معالجة مشكلة تخزين كلمة المرور والاختبار.
هناك مقالات عن اختبار قواعد اللعبة:
# Ansible: اختبار قواعد اللعبة (الجزء الأول)
# اختبار والتكامل المستمر للأدوار Ansible مع جزيء وجينكينز
إجابات على الأسئلة
1) Mentat: ولماذا ، بعد كل شيء ، أليس كذلك كيف هو مكتوب في قفص الاتهام ansible ، مع البيئات؟ من القراءة الأولى ، تبدو كمحاولة لإعادة اختراعها من جديد. من الملائم تمامًا تطبيق كل هذا على غرار ansible-playbook -i env / teamA personalAPlaybook.yml
الإجابة: هذا المخطط يجعل من الممكن تغيير الإعدادات العامة. ما هو موضح في السؤال هو تغيير الإعدادات المحلية للأوامر.
PS ربما يتم تنفيذ نفس الوظيفة في برج Ansible. لكنني لا أستطيع قول أي شيء عن هذا - لم أكن أعمل مع برج أنسبل.