উত্তরযোগ্য ভেরিয়েবলের জন্য সিস্টেম পদ্ধতি

উত্তরযোগ্য ডিভোপস কোডস্টাইল

আরে! আমার নাম ডেনিস কাল্যুঝনি আমি উন্নয়ন প্রক্রিয়া অটোমেশন বিভাগে একজন প্রকৌশলী হিসাবে কাজ করি। প্রতিদিন, শত শত প্রচার সার্ভারে নতুন অ্যাপ্লিকেশন তৈরি করা হয়। এবং এই নিবন্ধে, আমি এই উদ্দেশ্যে Ansible ব্যবহার করার আমার অভিজ্ঞতা শেয়ার করছি।

এই নির্দেশিকা একটি স্থাপনায় ভেরিয়েবল সংগঠিত করার একটি উপায় প্রস্তাব করে। এই গাইডটি তাদের জন্য ডিজাইন করা হয়েছে যারা ইতিমধ্যেই তাদের প্লেবুকগুলিতে ভূমিকা ব্যবহার করে এবং পড়ে সেরা অনুশীলনকিন্তু অনুরূপ সমস্যার মধ্যে চলছে:

• কোডে একটি ভেরিয়েবল পাওয়া গেলে, এটি কীসের জন্য দায়ী তা অবিলম্বে বোঝা অসম্ভব;
• বিভিন্ন ভূমিকা আছে, এবং ভেরিয়েবলগুলিকে একটি মানের সাথে যুক্ত করতে হবে, কিন্তু এটি কাজ করে না;
• আপনার প্লেবুকের ভেরিয়েবলের যুক্তি কীভাবে কাজ করে তা অন্যদের ব্যাখ্যা করতে অসুবিধা হচ্ছে

আমরা আমাদের কোম্পানির প্রকল্পগুলিতে এই সমস্যার সম্মুখীন হয়েছি, যার ফলস্বরূপ আমরা আমাদের প্লেবুকগুলিতে ভেরিয়েবলগুলি ফর্ম্যাট করার নিয়মগুলিতে এসেছি, যা কিছু পরিমাণে এই সমস্যার সমাধান করেছে।

ভূমিকা পরিবর্তনশীল

একটি ভূমিকা একটি পৃথক স্থাপনার সিস্টেম অবজেক্ট। সিস্টেমের যেকোনো বস্তুর মতো, এটির অবশ্যই বাকি সিস্টেমের সাথে ইন্টারফেস করার জন্য একটি ইন্টারফেস থাকতে হবে। ভূমিকা ভেরিয়েবল যেমন একটি ইন্টারফেস.

উদাহরণস্বরূপ, ভূমিকা নিন api, যা সার্ভারে একটি জাভা অ্যাপ্লিকেশন ইনস্টল করে। এটা কি ভেরিয়েবল আছে?

ভূমিকা ভেরিয়েবল টাইপ দ্বারা 2 প্রকারে বিভক্ত করা যেতে পারে:

1. Свойства
    a) независимые от среды
    б) зависимые от среды
2. Связи
    a) слушатели 
    б) запросы внутри системы
    в) запросы в среду

পরিবর্তনশীল বৈশিষ্ট্য ভেরিয়েবল যা একটি ভূমিকার আচরণ সংজ্ঞায়িত করে।

ক্যোয়ারী ভেরিয়েবল ভেরিয়েবল যার মান ভূমিকার বাইরের সম্পদ নির্ধারণ করতে ব্যবহৃত হয়।

পরিবর্তনশীল শ্রোতা ভেরিয়েবল যার মান ক্যোয়ারী ভেরিয়েবল গঠন করতে ব্যবহৃত হয়।

অন্যদিকে, 1a, 2a, 2b হল ভেরিয়েবল যা পরিবেশের উপর নির্ভর করে না (লোহা, বাহ্যিক সম্পদ, ইত্যাদি) এবং ডিফল্ট ভূমিকায় ডিফল্ট মান দিয়ে পূর্ণ করা যেতে পারে। যাইহোক, 1.b এবং 2.c এর মত ভেরিয়েবলগুলি 'উদাহরণ' ছাড়া অন্য মান দিয়ে পূর্ণ করা যাবে না, কারণ তারা পরিবেশের উপর নির্ভর করে স্ট্যান্ড থেকে স্ট্যান্ডে পরিবর্তিত হবে।

কোড শৈলী

• ভেরিয়েবলের নাম ভূমিকার নাম দিয়ে শুরু করতে হবে। এটি ভেরিয়েবলটি কোন ভূমিকা থেকে এবং এটি কিসের জন্য দায়ী তা ভবিষ্যতে নির্ণয় করা সহজ করে তুলবে৷
• ভূমিকাগুলিতে ভেরিয়েবলগুলি ব্যবহার করার সময়, আপনাকে অবশ্যই এনক্যাপসুলেশন নীতি অনুসরণ করতে হবে এবং ভূমিকাতে বা বর্তমানটি নির্ভর করে এমন ভূমিকাগুলিতে সংজ্ঞায়িত ভেরিয়েবলগুলি ব্যবহার করতে হবে।

• ভেরিয়েবলের জন্য অভিধান ব্যবহার করা এড়িয়ে চলুন। Ansible আপনাকে একটি অভিধানে স্বতন্ত্র মানগুলিকে সুবিধামত ওভাররাইড করার অনুমতি দেয় না।

  একটি খারাপ ভেরিয়েবলের একটি উদাহরণ:

  myrole_user:
      login: admin
      password: admin

  এখানে, লগইন হল মিডিয়ান ভেরিয়েবল এবং পাসওয়ার্ড হল নির্ভরশীল ভেরিয়েবল। কিন্তু
  যেহেতু এগুলি একটি অভিধানে একত্রিত হয়েছে, তাই আপনাকে এটি সম্পূর্ণভাবে উল্লেখ করতে হবে
  সর্বদা. যা খুবই অসুবিধাজনক। এইভাবে ভাল:

  myrole_user_login: admin
  myrole_user_password: admin

স্থাপনার playbooks মধ্যে ভেরিয়েবল

একটি স্থাপনার প্লেবুক কম্পাইল করার সময় (এরপরে একটি প্লেবুক হিসাবে উল্লেখ করা হয়েছে), আমরা নিয়ম মেনে চলি যে এটি একটি পৃথক সংগ্রহস্থলে স্থাপন করা উচিত। ঠিক যেমন ভূমিকা: প্রতিটি তার নিজস্ব গিট সংগ্রহস্থলে। এটি আপনাকে উপলব্ধি করতে দেয় যে ভূমিকা এবং প্লেবুক ডিপ্লয়মেন্ট সিস্টেমের বিভিন্ন স্বাধীন বস্তু, এবং একটি বস্তুর পরিবর্তন অন্যটির অপারেশনকে প্রভাবিত করবে না। এটি ভেরিয়েবলের ডিফল্ট মান পরিবর্তন করে অর্জন করা হয়।

একটি প্লেবুক কম্পাইল করার সময়, সারসংক্ষেপে, রোল ভেরিয়েবলের ডিফল্ট মান দুটি জায়গায় ওভাররাইড করা সম্ভব: প্লেবুক ভেরিয়েবলে এবং ইনভেন্টরি ভেরিয়েবলে।

mydeploy                        # Каталог деплоя
├── deploy.yml                  # Плейбук деплоя
├── group_vars                  # Каталог переменных плейбука
│   ├── all.yml                 # Файл для переменных связи всей системы
│   └── myapi.yml               # Файл переменных свойств группы myapi
└── inventories                 #
    └── prod                    # Каталог окружения prod
        ├── prod.ini            # Инвентори файл
        └── group_vars          # Каталог для переменных инвентори
            └── myapi           #
                ├── vars.yml    # Средозависимые переменные группы myapi
                └── vault.yml   # Секреты (всегда средозависимы) *

* - ভেরিয়েবল এবং ভল্ট

পার্থক্য হল যে প্লেবুক ভেরিয়েবলগুলি সর্বদা ব্যবহার করা হয় যখন এটির সাথে একই স্তরে অবস্থিত প্লেবুকগুলিকে কল করা হয়। এর মানে হল যে এই ভেরিয়েবলগুলি পরিবেশের উপর নির্ভর করে না এমন ভেরিয়েবলের ডিফল্ট মান পরিবর্তন করার জন্য দুর্দান্ত। বিপরীতভাবে, ইনভেন্টরি ভেরিয়েবল শুধুমাত্র একটি নির্দিষ্ট পরিবেশের জন্য ব্যবহার করা হবে, যা পরিবেশ-নির্দিষ্ট ভেরিয়েবলের জন্য আদর্শ।

এটি লক্ষ করা গুরুত্বপূর্ণ যে পরিবর্তনশীল অগ্রাধিকার আপনাকে প্রথমে প্লেবুক ভেরিয়েবলে এবং তারপর একই ইনভেন্টরিতে আলাদাভাবে ভেরিয়েবলগুলিকে পুনরায় সংজ্ঞায়িত করার অনুমতি দেবে না।

এর মানে হল যে ইতিমধ্যে এই পর্যায়ে আপনাকে সিদ্ধান্ত নিতে হবে যে ভেরিয়েবলটি পরিবেশ-নির্ভর কিনা এবং এটিকে সঠিক জায়গায় স্থাপন করতে হবে।

উদাহরণস্বরূপ, একটি প্রকল্পে, SSL সক্ষম করার জন্য দায়ী ভেরিয়েবলটি দীর্ঘ সময়ের জন্য পরিবেশ-নির্ভর ছিল, যেহেতু আমরা একটি স্ট্যান্ডে আমাদের নিয়ন্ত্রণের বাইরের কারণে SSL সক্ষম করতে পারিনি। আমরা এই সমস্যাটি ঠিক করার পরে, এটি মাঝারি স্বাধীন হয়ে উঠেছে এবং প্লেবুক ভেরিয়েবলে চলে গেছে।

গোষ্ঠীর জন্য সম্পত্তি ভেরিয়েবল

চলুন চিত্র 1-এ আমাদের মডেলটিকে প্রসারিত করা যাক একটি ভিন্ন জাভা অ্যাপ্লিকেশন সহ সার্ভারের 2টি গ্রুপ যোগ করে, কিন্তু ভিন্ন সেটিংস সহ।

এই ক্ষেত্রে প্লেবুকটি কেমন হবে তা কল্পনা করুন:

- hosts: myapi
  roles:
    - api

- hosts: bbauth
  roles:
    - auth

- hosts: ghauth
  roles:
    - auth

আমাদের প্লেবুকে তিনটি গ্রুপ আছে, তাই একবারে গ্রুপ_ভারস ইনভেন্টরি ভেরিয়েবল এবং প্লেবুক ভেরিয়েবলে যতগুলি গ্রুপ ফাইল তৈরি করার পরামর্শ দেওয়া হচ্ছে। এই ক্ষেত্রে একটি গ্রুপ ফাইল হল প্লেবুকে আপনার অ্যাপ্লিকেশনের একটি উপাদানের বিবরণ। আপনি যখন প্লেবুক ভেরিয়েবলে গ্রুপ ফাইলটি খুলবেন, আপনি অবিলম্বে গ্রুপে নির্ধারিত ভূমিকাগুলির ডিফল্ট আচরণ থেকে সমস্ত পার্থক্য দেখতে পাবেন। ইনভেন্টরি ভেরিয়েবলে: বুথ থেকে বুথে গ্রুপ আচরণের পার্থক্য।

কোড স্টাইল

• host_vars ভেরিয়েবলগুলি ব্যবহার না করার চেষ্টা করুন, কারণ তারা সিস্টেমটি বর্ণনা করে না, তবে শুধুমাত্র একটি বিশেষ ক্ষেত্রে, যা দীর্ঘমেয়াদে প্রশ্নগুলির দিকে নিয়ে যাবে: "কেন এই হোস্টটি বাকিদের থেকে আলাদা?", যার উত্তর হল খুঁজে পাওয়া সবসময় সহজ নয়।

লিঙ্ক ভেরিয়েবল

যাইহোক, যে সম্পত্তি ভেরিয়েবল সম্পর্কে, কিন্তু লিঙ্ক ভেরিয়েবল সম্পর্কে কি?
তাদের পার্থক্য হল বিভিন্ন গ্রুপে তাদের অবশ্যই একই মান থাকতে হবে।

শুরুতে ছিল ধারণা ফর্মের একটি দানবীয় নির্মাণ ব্যবহার করুন:
hostvars[groups['bbauth'][0]]['auth_bind_port'], কিন্তু তা অবিলম্বে পরিত্যক্ত হয়েছিল
কারণ এতে ত্রুটি রয়েছে। প্রথমত, বিশালতা। দ্বিতীয়ত, গ্রুপে একটি নির্দিষ্ট হোস্টের উপর নির্ভরতা। তৃতীয়ত, স্থাপনা শুরু করার আগে সমস্ত হোস্ট থেকে তথ্য সংগ্রহ করা প্রয়োজন, যদি আমরা একটি অনির্ধারিত পরিবর্তনশীল ত্রুটি পেতে না চাই।

ফলস্বরূপ, লিঙ্ক ভেরিয়েবল ব্যবহার করার সিদ্ধান্ত নেওয়া হয়েছিল।

লিঙ্ক ভেরিয়েবল ভেরিয়েবল যা প্লেবুকের অন্তর্গত এবং সিস্টেম অবজেক্ট লিঙ্ক করার জন্য প্রয়োজন।

লিংক ভেরিয়েবলগুলি সাধারণ সিস্টেম ভেরিয়েবলে পপুলেট করা হয় group_vars/all/vars এবং প্রতিটি গ্রুপ থেকে সমস্ত শ্রোতা ভেরিয়েবল মুছে ফেলা এবং ভেরিয়েবলের শুরুতে যে গ্রুপ থেকে শ্রোতাকে সরানো হয়েছে তার নাম যোগ করে গঠিত হয়।

এইভাবে, নামের অভিন্নতা এবং অ-ছেদ নিশ্চিত করা হয়।

চলুন উপরের উদাহরণ থেকে ভেরিয়েবল বাঁধার চেষ্টা করি:

কল্পনা করুন যে আমাদের ভেরিয়েবল রয়েছে যা একে অপরের উপর নির্ভর করে:

# roles/api/defaults:
# Переменная запроса
api_auth1_address: "http://example.com:80"
api_auth2_address: "http://example2.com:80"

# roles/auth/defaults:
# Переменная слушатель
auth_bind_port: "20000"

এটাকে সাধারণ ভেরিয়েবলে রাখি group_vars/all/vars সমস্ত শ্রোতা, এবং নামের সাথে গ্রুপের নাম যোগ করুন:

# group_vars/all/vars
bbauth_auth_bind_port: "20000"
ghauth_auth_bind_port: "30000"

# group_vars/bbauth/vars
auth_bind_port: "{{ bbauth_auth_bind_port }}"

# group_vars/ghauth/vars
auth_bind_port: "{{ ghauth_auth_bind_port }}"

# group_vars/myapi/vars
api_auth1_address: "http://{{ bbauth_auth_service_name }}:{{ bbauth_auth_bind_port }}"
api_auth2_address: "http://{{ ghauth_auth_service_name }}:{{ ghauth_auth_bind_port }}"

এখন, সংযোগকারীর মান পরিবর্তন করে, আমরা নিশ্চিত হব যে অনুরোধটি একই পোর্টে যাবে।

কোড স্টাইল

• যেহেতু ভূমিকা এবং গোষ্ঠীগুলি বিভিন্ন সিস্টেম অবজেক্ট, তাই তাদের আলাদা নাম থাকতে হবে যাতে লিঙ্ক ভেরিয়েবলগুলি সঠিকভাবে দেখায় যে তারা একটি নির্দিষ্ট সার্ভার গ্রুপের অন্তর্গত, এবং সিস্টেমের একটি ভূমিকার নয়।

পরিবেশ ফাইল

ভূমিকা পরিবেশ থেকে পরিবেশে ভিন্ন ফাইল ব্যবহার করতে পারে।

SSL সার্টিফিকেট এই ধরনের ফাইলের একটি উদাহরণ। টেক্সট হিসাবে তাদের সংরক্ষণ করুন
একটি পরিবর্তনশীল মধ্যে খুব সুবিধাজনক নয়. কিন্তু একটি ভেরিয়েবলের ভিতরে তাদের পথ সংরক্ষণ করা সুবিধাজনক।

উদাহরণস্বরূপ, আমরা ভেরিয়েবল ব্যবহার করি api_ssl_key_file: "/path/to/file".

যেহেতু এটি স্পষ্ট যে কী শংসাপত্রটি পরিবেশ থেকে পরিবেশে পরিবর্তিত হবে, এটি একটি পরিবেশ-নির্ভর পরিবর্তনশীল, যার মানে এটি ফাইলে অবস্থিত হওয়া উচিত
group_vars/myapi/vars ভেরিয়েবলের ইনভেন্টরি, এবং 'উদাহরণস্বরূপ' মান ধারণ করে।

এই ক্ষেত্রে সবচেয়ে সুবিধাজনক উপায় হল প্লেবুক রিপোজিটরিতে কী ফাইলটি পাথ বরাবর রাখা
files/prod/certs/myapi.key, তাহলে ভেরিয়েবলের মান হবে:
api_ssl_key_file: "prod/certs/myapi.key". সুবিধাটি এই সত্যের মধ্যে রয়েছে যে একটি নির্দিষ্ট স্ট্যান্ডে সিস্টেমটি স্থাপনের জন্য দায়ী ব্যক্তিদেরও তাদের ফাইলগুলি সংরক্ষণ করার জন্য সংগ্রহস্থলে তাদের নিজস্ব উত্সর্গীকৃত স্থান রয়েছে। একই সময়ে, সার্ভারে সার্টিফিকেটের নিখুঁত পথ নির্দিষ্ট করা সম্ভব, যদি শংসাপত্রগুলি অন্য সিস্টেম দ্বারা সরবরাহ করা হয়।

এক পরিবেশে একাধিক দাঁড়ানো

প্রায়শই ন্যূনতম পার্থক্য সহ একই পরিবেশে বেশ কয়েকটি প্রায় অভিন্ন স্ট্যান্ড স্থাপন করার প্রয়োজন হয়। এই ক্ষেত্রে, আমরা পরিবেশ-নির্ভর ভেরিয়েবলগুলিকে ভাগ করি যেগুলি এই পরিবেশের মধ্যে পরিবর্তন হয় না এবং যেগুলি করে। এবং আমরা পরেরটি সরাসরি ইনভেন্টরি ফাইলের মধ্যে নিয়ে যাই। এই ম্যানিপুলেশনের পরে, পরিবেশ ডিরেক্টরিতে সরাসরি অন্য ইনভেন্টরি তৈরি করা সম্ভব হয়।

এটি group_vars ইনভেন্টরি পুনরায় ব্যবহার করবে এবং কিছু ভেরিয়েবলকে সরাসরি নিজের জন্য পুনরায় সংজ্ঞায়িত করতে সক্ষম হবে।

স্থাপনা প্রকল্পের জন্য চূড়ান্ত ডিরেক্টরি কাঠামো:

mydeploy                        # Каталог деплоя
├── deploy.yml                  # Плейбук деплоя
├── files                       # Каталог для файлов деплоя
│   ├── prod                    # Католог для средозависимых файлов стенда prod
│   │   └── certs               # 
│   │       └── myapi.key       #
│   └── test1                   # Каталог для средозависимых файлов стенда test1
├── group_vars                  # Каталог переменных плейбука
│   ├── all.yml                 # Файл для переменных связи всей системы
│   ├── myapi.yml               # Файл переменных свойств группы myapi
│   ├── bbauth.yml              # 
│   └── ghauth.yml              #
└── inventories                 #
    ├── prod                    # Каталог окружения prod
    │   ├── group_vars          # Каталог для переменных инвентори
    │   │   ├── myapi           #
    │   │   │   ├── vars.yml    # Средозависимые переменные группы myapi
    │   │   │   └── vault.yml   # Секреты (всегда средозависимы)
    │   │   ├── bbauth          # 
    │   │   │   ├── vars.yml    #
    │   │   │   └── vault.yml   #
    │   │   └── ghauth          #
    │   │       ├── vars.yml    #
    │   │       └── vault.yml   #
    │   └── prod.ini            # Инвентори стенда prod
    └── test                    # Каталог окружения test
        ├── group_vars          #
        │   ├── myapi           #
        │   │   ├── vars.yml    #
        │   │   └── vault.yml   #
        │   ├── bbauth          #
        │   │   ├── vars.yml    #
        │   │   └── vault.yml   #
        │   └── ghauth          #
        │       ├── vars.yml    #
        │       └── vault.yml   #
        ├── test1.ini           # Инвентори стенда test1 в среде test
        └── test2.ini           # Инвентори стенда test2 в среде test

সাতরে যাও

নিবন্ধ অনুসারে ভেরিয়েবলগুলি সংগঠিত করার পরে: ভেরিয়েবল সহ প্রতিটি ফাইল একটি নির্দিষ্ট কাজের জন্য দায়ী। এবং যেহেতু ফাইলটির কিছু নির্দিষ্ট কাজ রয়েছে, তাই প্রতিটি ফাইলের সঠিকতার জন্য একজন ব্যক্তিকে দায়িত্ব দেওয়া সম্ভব হয়েছে। উদাহরণস্বরূপ, সিস্টেম স্থাপনার বিকাশকারী প্লেবুক ভেরিয়েবলের সঠিক ভেরিয়েবলের জন্য দায়ী, যখন প্রশাসক, যার স্ট্যান্ড ইনভেন্টরিতে বর্ণনা করা হয়েছে, ভেরিয়েবলের ইনভেন্টরি পূরণের জন্য সরাসরি দায়ী।

ভূমিকাগুলি তাদের নিজস্ব ইন্টারফেসের সাথে একটি স্বয়ংসম্পূর্ণ উন্নয়ন ইউনিটে পরিণত হয়েছে, যা ভূমিকা বিকাশকারীকে সিস্টেমের সাথে মানানসই ভূমিকাকে সাজানোর পরিবর্তে বৈশিষ্ট্যগুলি বিকাশ করতে দেয়৷ এই সমস্যাটি প্রচারাভিযানের সমস্ত সিস্টেমের জন্য সাধারণ ভূমিকার জন্য বিশেষভাবে সত্য ছিল।

সিস্টেম অ্যাডমিনিস্ট্রেটরদের আর ডিপ্লয়মেন্ট কোড বুঝতে হবে না। একটি সফল স্থাপনার জন্য তাদের যা প্রয়োজন তা হল পরিবেশ ভেরিয়েবলের ফাইলগুলি পূরণ করা।

সাহিত্য

1. Документация

লেখক

কালিজনি ডেনিস আলেকজান্দ্রোভিচ

উত্স: www.habr.com