ਜਵਾਬ ਵਿੱਚ ਵੇਰੀਏਬਲਾਂ ਲਈ ਸਿਸਟਮ ਪਹੁੰਚ

ਜਵਾਬਦੇਹ ਡਿਵੋਪਸ ਕੋਡਸਟਾਈਲ

ਹੇ! ਮੇਰਾ ਨਾਮ ਹੈ ਡੇਨਿਸ ਕਲਯੁਜ਼ਨੀ ਮੈਂ ਵਿਕਾਸ ਪ੍ਰਕਿਰਿਆ ਆਟੋਮੇਸ਼ਨ ਵਿਭਾਗ ਵਿੱਚ ਇੱਕ ਇੰਜੀਨੀਅਰ ਵਜੋਂ ਕੰਮ ਕਰਦਾ ਹਾਂ। ਹਰ ਰੋਜ਼, ਸੈਂਕੜੇ ਮੁਹਿੰਮ ਸਰਵਰਾਂ 'ਤੇ ਨਵੇਂ ਐਪਲੀਕੇਸ਼ਨ ਬਿਲਡਾਂ ਨੂੰ ਰੋਲ ਆਊਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਅਤੇ ਇਸ ਲੇਖ ਵਿੱਚ ਮੈਂ ਇਹਨਾਂ ਉਦੇਸ਼ਾਂ ਲਈ ਜਵਾਬਦੇਹ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦਾ ਆਪਣਾ ਅਨੁਭਵ ਸਾਂਝਾ ਕਰਦਾ ਹਾਂ।

ਇਹ ਗਾਈਡ ਤੈਨਾਤੀ ਵਿੱਚ ਵੇਰੀਏਬਲਾਂ ਨੂੰ ਸੰਗਠਿਤ ਕਰਨ ਦਾ ਇੱਕ ਤਰੀਕਾ ਪੇਸ਼ ਕਰਦੀ ਹੈ। ਇਹ ਗਾਈਡ ਉਹਨਾਂ ਲਈ ਹੈ ਜੋ ਪਹਿਲਾਂ ਹੀ ਆਪਣੀਆਂ ਪਲੇਬੁੱਕਾਂ ਵਿੱਚ ਭੂਮਿਕਾਵਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ ਅਤੇ ਪੜ੍ਹ ਚੁੱਕੇ ਹਨ ਵਧੀਆ ਅਭਿਆਸ, ਪਰ ਸਮਾਨ ਸਮੱਸਿਆਵਾਂ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪੈਂਦਾ ਹੈ:

• ਕੋਡ ਵਿੱਚ ਇੱਕ ਵੇਰੀਏਬਲ ਲੱਭਣ ਤੋਂ ਬਾਅਦ, ਇਹ ਤੁਰੰਤ ਸਮਝਣਾ ਅਸੰਭਵ ਹੈ ਕਿ ਇਹ ਕਿਸ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੈ;
• ਇੱਥੇ ਕਈ ਭੂਮਿਕਾਵਾਂ ਹਨ, ਅਤੇ ਵੇਰੀਏਬਲਾਂ ਨੂੰ ਇੱਕ ਮੁੱਲ ਨਾਲ ਜੋੜਨ ਦੀ ਲੋੜ ਹੈ, ਪਰ ਇਹ ਕੰਮ ਨਹੀਂ ਕਰਦਾ;
• ਦੂਜਿਆਂ ਨੂੰ ਸਮਝਾਉਣ ਵਿੱਚ ਮੁਸ਼ਕਲ ਆ ਰਹੀ ਹੈ ਕਿ ਤੁਹਾਡੀਆਂ ਪਲੇਬੁੱਕਾਂ ਵਿੱਚ ਵੇਰੀਏਬਲਾਂ ਦਾ ਤਰਕ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ

ਸਾਨੂੰ ਸਾਡੀ ਕੰਪਨੀ ਵਿੱਚ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ ਇਹਨਾਂ ਸਮੱਸਿਆਵਾਂ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪਿਆ, ਜਿਸ ਦੇ ਨਤੀਜੇ ਵਜੋਂ ਅਸੀਂ ਆਪਣੀਆਂ ਪਲੇਬੁੱਕਾਂ ਵਿੱਚ ਵੇਰੀਏਬਲ ਡਿਜ਼ਾਈਨ ਕਰਨ ਦੇ ਨਿਯਮਾਂ 'ਤੇ ਆਏ, ਜਿਸ ਨੇ ਕੁਝ ਹੱਦ ਤੱਕ ਇਹਨਾਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕੀਤਾ।

ਭੂਮਿਕਾਵਾਂ ਵਿੱਚ ਵੇਰੀਏਬਲ

ਇੱਕ ਰੋਲ ਡਿਪਲਾਇਮੈਂਟ ਸਿਸਟਮ ਦਾ ਇੱਕ ਵੱਖਰਾ ਵਸਤੂ ਹੈ। ਕਿਸੇ ਵੀ ਸਿਸਟਮ ਆਬਜੈਕਟ ਦੀ ਤਰ੍ਹਾਂ, ਇਸਦਾ ਬਾਕੀ ਸਿਸਟਮ ਨਾਲ ਇੰਟਰਫੇਸ ਕਰਨ ਲਈ ਇੱਕ ਇੰਟਰਫੇਸ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਅਜਿਹਾ ਇੰਟਰਫੇਸ ਰੋਲ ਵੇਰੀਏਬਲ ਹੈ।

ਆਓ, ਉਦਾਹਰਨ ਲਈ, ਭੂਮਿਕਾ ਨੂੰ ਲੈ ਲਈਏ api, ਜੋ ਸਰਵਰ 'ਤੇ ਇੱਕ Java ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਸਥਾਪਿਤ ਕਰਦਾ ਹੈ। ਇਸ ਵਿੱਚ ਕਿਹੜੇ ਵੇਰੀਏਬਲ ਹੋ ਸਕਦੇ ਹਨ?

ਪਰਿਵਰਤਨਸ਼ੀਲ ਭੂਮਿਕਾਵਾਂ ਨੂੰ ਕਿਸਮ ਦੇ ਅਨੁਸਾਰ 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

ਤੈਨਾਤੀ ਪਲੇਬੁੱਕ ਵਿੱਚ ਵੇਰੀਏਬਲ

ਜਦੋਂ ਇੱਕ ਡਿਪਲਾਇਮੈਂਟ ਪਲੇਬੁੱਕ (ਇਸ ਤੋਂ ਬਾਅਦ ਪਲੇਬੁੱਕ ਕਿਹਾ ਜਾਂਦਾ ਹੈ) ਨੂੰ ਕੰਪਾਇਲ ਕਰਦੇ ਹੋਏ, ਅਸੀਂ ਇਸ ਨਿਯਮ ਦੀ ਪਾਲਣਾ ਕਰਦੇ ਹਾਂ ਕਿ ਇਸਨੂੰ ਇੱਕ ਵੱਖਰੇ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਰੱਖਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਭੂਮਿਕਾਵਾਂ ਦੇ ਸਮਾਨ: ਹਰ ਇੱਕ ਆਪਣੀ ਆਪਣੀ ਗਿੱਟ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ. ਇਹ ਤੁਹਾਨੂੰ ਇਹ ਸਮਝਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ ਕਿ ਰੋਲ ਅਤੇ ਪਲੇਬੁੱਕ ਡਿਪਲਾਇਮੈਂਟ ਸਿਸਟਮ ਦੇ ਵੱਖ-ਵੱਖ ਸੁਤੰਤਰ ਆਬਜੈਕਟ ਹਨ, ਅਤੇ ਇੱਕ ਵਸਤੂ ਵਿੱਚ ਬਦਲਾਅ ਦੂਜੇ ਦੇ ਸੰਚਾਲਨ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਇਹ ਵੇਰੀਏਬਲ ਦੇ ਡਿਫਾਲਟ ਮੁੱਲਾਂ ਨੂੰ ਬਦਲ ਕੇ ਪ੍ਰਾਪਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

ਪਲੇਬੁੱਕ ਨੂੰ ਕੰਪਾਇਲ ਕਰਦੇ ਸਮੇਂ, ਸੰਖੇਪ ਕਰਨ ਲਈ, ਰੋਲ ਵੇਰੀਏਬਲ ਦੇ ਡਿਫੌਲਟ ਮੁੱਲਾਂ ਨੂੰ ਦੋ ਥਾਵਾਂ 'ਤੇ ਓਵਰਰਾਈਡ ਕਰਨਾ ਸੰਭਵ ਹੈ: ਪਲੇਬੁੱਕ ਵੇਰੀਏਬਲਾਂ ਅਤੇ ਇਨਵੈਂਟਰੀ ਵੇਰੀਏਬਲਾਂ ਵਿੱਚ।

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