ਇਹ ਦਸਤਾਵੇਜ਼ ਆਰਕੀਟੈਕਟਾਂ ਅਤੇ ਉਹਨਾਂ ਲੋਕਾਂ ਲਈ ਹੈ ਜੋ ਸੰਚਾਲਨ ਅਤੇ ਪ੍ਰਬੰਧਕੀ ਟੀਮਾਂ ਵਿੱਚ ਕੰਮ ਕਰਦੇ ਹਨ। ਦਸਤਾਵੇਜ਼ ਇੱਕ ਉਦਾਹਰਨ ਪੈਟਰਨ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ ਜਿਸਦੀ ਵਰਤੋਂ ਤੁਸੀਂ Google ਕਲਾਉਡ ਵਿੱਚ ਆਪਣੀ ਖੁਦ ਦੀ ਤੈਨਾਤੀ ਲਈ ਕਰ ਸਕਦੇ ਹੋ

ਇਸ ਪੈਟਰਨ ਵਿੱਚ, ਕਲਾਉਡ DNS ਟ੍ਰੈਫਿਕ ਨੂੰ ਪ੍ਰਬੰਧਿਤ ਉਦਾਹਰਨ ਸਮੂਹਾਂ ਵਿੱਚ ਕੰਪਿਊਟ ਇੰਜਣ ਉਦਾਹਰਨਾਂ ਲਈ ਨਿਰਦੇਸ਼ਿਤ ਕਰਦਾ ਹੈ ਜੋ ਸਮੱਗਰੀ ਦੀ ਸੇਵਾ ਕਰਦੇ ਹਨ। ਆਊਟੇਜ ਵਿੱਚ, ਤੁਸੀਂ ਕਲਾਊਡ DNS ਜ਼ੋਨ ਨੂੰ ਅੱਪਡੇਟ ਕਰਦੇ ਹੋ ਅਤੇ ਕਲਾਊਡ ਸਟੋਰੇਜ ਵਿੱਚ ਇੱਕ ਸਥਿਰ ਸਾਈਟ 'ਤੇ ਫੇਲ ਹੋ ਜਾਂਦੇ ਹੋ

ਇਸ ਟਿਊਟੋਰਿਅਲ ਨੂੰ ਪੂਰਾ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਇੱਕ ਰਜਿਸਟਰਡ ਡੋਮੇਨ ਨਾਮ ਦੀ ਲੋੜ ਹੈ ਜਿਸਨੂੰ ਤੁਸੀਂ ਕੰਟਰੋਲ ਕਰਦੇ ਹੋ ਅਤੇ ਇਸ ਦਸਤਾਵੇਜ਼ ਨਾਲ ਵਰਤਣਾ ਚਾਹੁੰਦੇ ਹੋ

ਉਤਪਾਦਨ ਤੈਨਾਤੀਆਂ ਵਿੱਚ, ਤੁਹਾਡੀ ਵੈਬਸਾਈਟ ਵਿੱਚ ਸੰਭਾਵਤ ਤੌਰ 'ਤੇ ਇਸ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਦਿਖਾਈਆਂ ਗਈਆਂ ਤੁਹਾਡੀਆਂ ਪ੍ਰਬੰਧਿਤ ਉਦਾਹਰਣਾਂ ਸਮੂਹ ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ (VMs) 'ਤੇ ਬਹੁਤ ਸਾਰੀਆਂ ਹੋਰ ਫਾਈਲਾਂ ਅਤੇ ਵਾਧੂ ਐਪਲੀਕੇਸ਼ਨ ਕੋਡ ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ। ਕਲਾਉਡ ਸਟੋਰੇਜ ਫਿਰ ਇੱਕ ਹੋਰ ਸੀਮਤ ਸਥਿਰ ਸੰਸਕਰਣ ਦੀ ਮੇਜ਼ਬਾਨੀ ਕਰਦਾ ਹੈ ਜੋ ਘੱਟੋ-ਘੱਟ ਕਾਰਜਸ਼ੀਲਤਾ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਇੱਕ ਨਿੱਘੇ ਫੇਲਓਵਰ ਦ੍ਰਿਸ਼ ਵਿੱਚ, ਉਪਭੋਗਤਾ ਇਸ ਸੀਮਤ ਵੈਬਸਾਈਟ ਨੂੰ ਉਦੋਂ ਤੱਕ ਦੇਖਦੇ ਹਨ ਜਦੋਂ ਤੱਕ ਪ੍ਰਬੰਧਿਤ ਉਦਾਹਰਣ ਸਮੂਹ ਠੀਕ ਨਹੀਂ ਹੋ ਜਾਂਦੇ ਅਤੇ ਪੂਰੀ ਵੈਬਸਾਈਟ ਅਨੁਭਵ ਲਈ ਟ੍ਰੈਫਿਕ ਦੀ ਸੇਵਾ ਕਰ ਸਕਦੇ ਹਨ

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

ਇੱਕ ਵਿਕਲਪਿਕ ਪਹੁੰਚ ਲਈ ਜੋ ਫੇਲਓਵਰ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਨ ਲਈ ਕਲਾਉਡ DNS ਦੀ ਬਜਾਏ ਬਾਹਰੀ HTTP(S) ਲੋਡ ਬੈਲੇਂਸਿੰਗ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ, ਕੰਪਿਊਟ ਇੰਜਣ ਅਤੇ ਕਲਾਉਡ ਸਟੋਰੇਜ ਦੇ ਨਾਲ ਇੱਕ ਨਿੱਘੇ ਮੁੜ ਪ੍ਰਾਪਤ ਕਰਨ ਯੋਗ ਵੈਬ ਸਰਵਰ ਨੂੰ ਤੈਨਾਤ ਕਰੋ ਵੇਖੋ। ਇਹ ਪੈਟਰਨ ਲਾਭਦਾਇਕ ਹੈ ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ ਕਲਾਊਡ DNS ਨਹੀਂ ਹੈ, ਜਾਂ ਤੁਸੀਂ ਵਰਤਣਾ ਨਹੀਂ ਚਾਹੁੰਦੇ ਹੋ

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

ਇਹ ਦਸਤਾਵੇਜ਼ ਇੱਕ ਬੁਨਿਆਦੀ ਅਪਾਚੇ ਵੈੱਬ ਸਰਵਰ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ, ਪਰ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੀ ਤੈਨਾਤੀ ਲਈ ਉਹੀ ਪਹੁੰਚ ਦੂਜੇ ਐਪਲੀਕੇਸ਼ਨ ਵਾਤਾਵਰਣਾਂ 'ਤੇ ਲਾਗੂ ਹੁੰਦੀ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੈ।

## ਉਦੇਸ਼

- ਇੱਕ ਕਸਟਮ VM ਚਿੱਤਰ ਨਾਲ ਖੇਤਰੀ ਪ੍ਰਬੰਧਿਤ ਉਦਾਹਰਨ ਸਮੂਹ ਬਣਾਓ

- ਇੱਕ ਕਲਾਉਡ ਸਟੋਰੇਜ ਬਾਲਟੀ ਬਣਾਓ

- ਇੱਕ ਕਲਾਉਡ DNS ਜ਼ੋਨ ਬਣਾਓ ਅਤੇ ਕੌਂਫਿਗਰ ਕਰੋ

- ਅੱਪਡੇਟ ਕੀਤੇ ਕਲਾਉਡ DNS ਰਿਕਾਰਡਾਂ ਨਾਲ ਗਰਮ ਵੈੱਬ ਸਰਵਰ ਫੇਲਓਵਰ ਦੀ ਜਾਂਚ ਕਰੋ

- ਅੱਪਡੇਟ ਕੀਤੇ ਕਲਾਉਡ DNS ਰਿਕਾਰਡਾਂ ਨਾਲ ਰਿਕਵਰੀ ਅਤੇ ਫੇਲਬੈਕ ਦੀ ਜਾਂਚ ਕਰੋ

## ਲਾਗਤਾਂ
ਇਹ ਟਿਊਟੋਰਿਅਲ ਗੂਗਲ ਕਲਾਉਡ ਦੇ ਨਿਮਨਲਿਖਤ ਬਿਲ ਯੋਗ ਭਾਗਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ:
ਤੁਹਾਡੇ ਅਨੁਮਾਨਿਤ ਵਰਤੋਂ ਦੇ ਆਧਾਰ 'ਤੇ ਲਾਗਤ ਦਾ ਅੰਦਾਜ਼ਾ ਬਣਾਉਣ ਲਈ,
ਕੀਮਤ ਕੈਲਕੁਲੇਟਰ ਦੀ ਵਰਤੋਂ ਕਰੋ

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

- ਆਪਣੇ ਗੂਗਲ ਕਲਾਉਡ ਖਾਤੇ ਵਿੱਚ ਸਾਈਨ ਇਨ ਕਰੋ। ਜੇਕਰ ਤੁਸੀਂ Google ਕਲਾਊਡ ਲਈ ਨਵੇਂ ਹੋ, ਤਾਂ ਇਹ ਮੁਲਾਂਕਣ ਕਰਨ ਲਈ ਇੱਕ ਖਾਤਾ ਬਣਾਓ ਕਿ ਸਾਡੇ ਉਤਪਾਦ ਅਸਲ-ਸੰਸਾਰ ਦ੍ਰਿਸ਼ਾਂ ਵਿੱਚ ਕਿਵੇਂ ਪ੍ਰਦਰਸ਼ਨ ਕਰਦੇ ਹਨ। ਨਵੇਂ ਗਾਹਕਾਂ ਨੂੰ ਵਰਕਲੋਡ ਨੂੰ ਚਲਾਉਣ, ਟੈਸਟ ਕਰਨ ਅਤੇ ਲਾਗੂ ਕਰਨ ਲਈ ਮੁਫ਼ਤ ਕ੍ਰੈਡਿਟ ਵਿੱਚ $300 ਵੀ ਪ੍ਰਾਪਤ ਹੁੰਦੇ ਹਨ

-
Google ਕਲਾਊਡ ਕੰਸੋਲ ਵਿੱਚ, ਪ੍ਰੋਜੈਕਟ ਚੋਣਕਾਰ ਪੰਨੇ 'ਤੇ, ਇੱਕ Google ਕਲਾਊਡ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਚੁਣੋ ਜਾਂ ਬਣਾਓ

-
ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਤੁਹਾਡੇ ਕਲਾਊਡ ਪ੍ਰੋਜੈਕਟ ਲਈ ਬਿਲਿੰਗ ਚਾਲੂ ਹੈ। ਕਿਸੇ ਪ੍ਰੋਜੈਕਟ 'ਤੇ ਬਿਲਿੰਗ ਯੋਗ ਹੈ ਜਾਂ ਨਹੀਂ ਇਸਦੀ ਜਾਂਚ ਕਰਨ ਦਾ ਤਰੀਕਾ ਜਾਣੋ

-
ਕੰਪਿਊਟ ਇੰਜਣ API ਨੂੰ ਸਮਰੱਥ ਬਣਾਓ

- ਗੂਗਲ ਕਲਾਉਡ ਸੀਐਲਆਈ ਨੂੰ ਸਥਾਪਿਤ ਅਤੇ ਅਰੰਭ ਕਰੋ

-
Google ਕਲਾਊਡ ਕੰਸੋਲ ਵਿੱਚ, ਪ੍ਰੋਜੈਕਟ ਚੋਣਕਾਰ ਪੰਨੇ 'ਤੇ, ਇੱਕ Google ਕਲਾਊਡ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਚੁਣੋ ਜਾਂ ਬਣਾਓ

-
ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਤੁਹਾਡੇ ਕਲਾਊਡ ਪ੍ਰੋਜੈਕਟ ਲਈ ਬਿਲਿੰਗ ਚਾਲੂ ਹੈ। ਕਿਸੇ ਪ੍ਰੋਜੈਕਟ 'ਤੇ ਬਿਲਿੰਗ ਯੋਗ ਹੈ ਜਾਂ ਨਹੀਂ ਇਸਦੀ ਜਾਂਚ ਕਰਨ ਦਾ ਤਰੀਕਾ ਜਾਣੋ

-
ਕੰਪਿਊਟ ਇੰਜਣ API ਨੂੰ ਸਮਰੱਥ ਬਣਾਓ

- ਗੂਗਲ ਕਲਾਉਡ ਸੀਐਲਆਈ ਨੂੰ ਸਥਾਪਿਤ ਅਤੇ ਅਰੰਭ ਕਰੋ

ਤੁਸੀਂ Google Cloud CLI ਨੂੰ ਸਥਾਪਿਤ ਕੀਤੇ ਬਿਨਾਂ Google Cloud ਕੰਸੋਲ ਵਿੱਚ Google Cloud CLI ਚਲਾ ਸਕਦੇ ਹੋ। ਗੂਗਲ ਕਲਾਉਡ ਕੰਸੋਲ ਵਿੱਚ gcloud CLI ਨੂੰ ਚਲਾਉਣ ਲਈ, ਕਲਾਉਡ ਸ਼ੈੱਲ ਦੀ ਵਰਤੋਂ ਕਰੋ

## ਵਾਤਾਵਰਨ ਨੂੰ ਤਿਆਰ ਕਰੋ
ਇਸ ਭਾਗ ਵਿੱਚ, ਤੁਸੀਂ ਆਪਣੇ ਸਰੋਤਾਂ ਦੇ ਨਾਮ ਅਤੇ ਸਥਾਨਾਂ ਲਈ ਕੁਝ ਵੇਰੀਏਬਲ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦੇ ਹੋ। ਇਹ ਵੇਰੀਏਬਲ Google Cloud CLI ਕਮਾਂਡਾਂ ਦੁਆਰਾ ਵਰਤੇ ਜਾਂਦੇ ਹਨ ਜਦੋਂ ਤੁਸੀਂ ਸਰੋਤਾਂ ਨੂੰ ਤੈਨਾਤ ਕਰਦੇ ਹੋ

ਇਸ ਟਿਊਟੋਰਿਅਲ ਦੇ ਦੌਰਾਨ, ਜਦੋਂ ਤੱਕ ਹੋਰ ਨੋਟ ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ, ਤੁਸੀਂ ਕਲਾਉਡ ਸ਼ੈੱਲ ਜਾਂ ਆਪਣੇ ਸਥਾਨਕ ਵਿਕਾਸ ਵਾਤਾਵਰਣ ਵਿੱਚ ਸਾਰੀਆਂ ਕਮਾਂਡਾਂ ਦਾਖਲ ਕਰਦੇ ਹੋ

ਬਦਲੋ
ਤੁਹਾਡੀ ਆਪਣੀ ਪ੍ਰੋਜੈਕਟ ਆਈਡੀ ਨਾਲ। ਜੇਕਰ ਲੋੜੀਦਾ ਹੋਵੇ, ਤਾਂ ਉਹਨਾਂ ਦੀ ਖੋਜ ਅਤੇ ਪਛਾਣ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਨ ਲਈ ਸਰੋਤਾਂ ਲਈ ਆਪਣਾ ਨਾਮ ਪਿਛੇਤਰ ਪ੍ਰਦਾਨ ਕਰੋ, ਜਿਵੇਂ ਕਿ
PROJECT_ID


ਐਪ
ਦੋ ਖੇਤਰ ਨਿਰਧਾਰਤ ਕਰੋ, ਜਿਵੇਂ ਕਿ
ਅਤੇ
us-west1
, ਅਤੇ ਉਹਨਾਂ ਖੇਤਰਾਂ ਵਿੱਚੋਂ ਇੱਕ ਦੇ ਅੰਦਰ ਇੱਕ ਜ਼ੋਨ, ਜਿਵੇਂ ਕਿ
us-west2
. ਇਹ ਜ਼ੋਨ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ ਕਿ ਸ਼ੁਰੂਆਤੀ ਅਧਾਰ VM ਕਿੱਥੇ ਬਣਾਇਆ ਗਿਆ ਹੈ ਜੋ ਪ੍ਰਬੰਧਿਤ ਉਦਾਹਰਨ ਸਮੂਹ ਲਈ ਇੱਕ ਚਿੱਤਰ ਬਣਾਉਣ ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ

us-west1-a
ਅੰਤ ਵਿੱਚ, ਇੱਕ ਡੋਮੇਨ ਸੈਟ ਕਰੋ ਜੋ ਤੁਹਾਡੀ ਸਥਿਰ ਵੈਬਸਾਈਟ ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, ਜਿਵੇਂ ਕਿ
example.com
PROJECT_ID=
PROJECT_IDNAME_SUFFIX= appREGION1= us-west1REGION2= us-west2ZONE= us-west1-aDOMAIN= example.com
## ਇੱਕ VPC ਅਤੇ ਸਬਨੈੱਟ ਬਣਾਓ
VM ਨੂੰ ਨੈੱਟਵਰਕ ਪਹੁੰਚ ਪ੍ਰਦਾਨ ਕਰਨ ਲਈ, ਤੁਸੀਂ ਵਰਚੁਅਲ ਪ੍ਰਾਈਵੇਟ ਕਲਾਊਡ (VPC) ਅਤੇ ਸਬਨੈੱਟ ਬਣਾਉਂਦੇ ਹੋ। ਜਿਵੇਂ ਕਿ ਤੁਹਾਨੂੰ ਦੋ ਖੇਤਰਾਂ ਵਿੱਚ ਪ੍ਰਬੰਧਿਤ ਉਦਾਹਰਨ ਸਮੂਹਾਂ ਦੀ ਲੋੜ ਹੈ, ਤੁਸੀਂ ਹਰੇਕ ਖੇਤਰ ਵਿੱਚ ਇੱਕ ਸਬਨੈੱਟ ਬਣਾਉਂਦੇ ਹੋ। ਤੁਹਾਡੇ ਵਾਤਾਵਰਣ ਵਿੱਚ ਵਰਤੋਂ ਵਿੱਚ ਆਈ ਪੀ ਐਡਰੈੱਸ ਰੇਂਜਾਂ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨ ਲਈ ਕਸਟਮ ਸਬਨੈੱਟ ਮੋਡ ਦੇ ਫਾਇਦਿਆਂ ਬਾਰੇ ਹੋਰ ਜਾਣਕਾਰੀ ਲਈ, ਕਸਟਮ ਮੋਡ VPC ਨੈੱਟਵਰਕ ਦੀ ਵਰਤੋਂ ਕਰੋ ਵੇਖੋ

ਇੱਕ ਕਸਟਮ ਸਬਨੈੱਟ ਮੋਡ ਨਾਲ VPC ਬਣਾਓ:
gcloud ਕੰਪਿਊਟ ਨੈੱਟਵਰਕ ਨੈੱਟਵਰਕ ਬਣਾਉਂਦੇ ਹਨ-$NAME_SUFFIX --subnet-mode=custom
ਹੁਣ ਨਵੇਂ VPC ਵਿੱਚ ਦੋ ਸਬਨੈੱਟ ਬਣਾਓ, ਹਰੇਕ ਖੇਤਰ ਲਈ ਇੱਕ। ਆਪਣੀਆਂ ਖੁਦ ਦੀਆਂ ਪਤਾ ਰੇਂਜਾਂ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ, ਜਿਵੇਂ ਕਿ
ਅਤੇ
10.1.0.0/20
, ਜੋ ਤੁਹਾਡੀ ਨੈੱਟਵਰਕ ਰੇਂਜ ਵਿੱਚ ਫਿੱਟ ਹੈ:
10.2.0.0/20
gcloud ਕੰਪਿਊਟ ਨੈੱਟਵਰਕ ਸਬਨੈੱਟ \ subnet-$NAME_SUFFIX-$REGION1 \ --network=network-$NAME_SUFFIX \ --range= ਬਣਾਉਂਦੇ ਹਨ
10.1.0.0/20\ --region=$REGION1 gcloud ਕੰਪਿਊਟ ਨੈੱਟਵਰਕ ਸਬਨੈੱਟ \ subnet-$NAME_SUFFIX-$REGION2 \ --network=network-$NAME_SUFFIX \ --range= 10.2.0.0/20\ --region=$ ਬਣਾਉਂਦੇ ਹਨ ਖੇਤਰ 2
## ਫਾਇਰਵਾਲ ਨਿਯਮ ਬਣਾਓ
VPC ਵਿੱਚ ਨੈੱਟਵਰਕ ਟ੍ਰੈਫਿਕ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਚੱਲਣ ਦੇਣ ਲਈ, ਫਾਇਰਵਾਲ ਨਿਯਮਾਂ ਦੀ ਵਰਤੋਂ ਕਰੋ

ਲੋਡ ਬੈਲੈਂਸਰ ਅਤੇ ਪ੍ਰਬੰਧਿਤ ਉਦਾਹਰਨ ਸਮੂਹਾਂ ਲਈ ਵੈਬ ਟ੍ਰੈਫਿਕ ਅਤੇ ਸਿਹਤ ਜਾਂਚਾਂ ਦੀ ਆਗਿਆ ਦੇਣ ਲਈ ਫਾਇਰਵਾਲ ਨਿਯਮ ਬਣਾਓ:
gcloud compute firewall-rules create allow-http-$NAME_SUFFIX \ --network=network-$NAME_SUFFIX \ --direction=INGRESS \ --priority=1000 \ --action=ALLOW \ --rules=tcp:80 \ -- source-ranges=0.0.0.0/0 \ --target-tags=http-server gcloud compute firewall-rules create allow-health-check-$NAME_SUFFIX \ --network=network-$NAME_SUFFIX \ --action=allow \ - -direction=ingress \ --source-ranges=130.211.0.0/22,35.191.0.0/16 \ --target-tags=allow-health-check \ --rules=tcp:80
HTTP ਨਿਯਮ ਕਿਸੇ ਵੀ VM ਲਈ ਟ੍ਰੈਫਿਕ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ ਜਿੱਥੇ
http-servertag ਲਾਗੂ ਕੀਤਾ ਗਿਆ ਹੈ, ਅਤੇ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਕਿਸੇ ਵੀ ਸਰੋਤ ਤੋਂ
0.0.0.0/0ਰੇਂਜ। ਸਿਹਤ ਜਾਂਚ ਨਿਯਮ ਲਈ, ਪਲੇਟਫਾਰਮ ਨੂੰ ਸਰੋਤਾਂ ਦੀ ਸਿਹਤ ਦੀ ਸਹੀ ਜਾਂਚ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦੇਣ ਲਈ Google ਕਲਾਊਡ ਲਈ ਪੂਰਵ-ਨਿਰਧਾਰਤ ਸੀਮਾਵਾਂ ਸੈੱਟ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ।

ਇੱਕ ਬੇਸ VM ਚਿੱਤਰ ਦੀ ਸ਼ੁਰੂਆਤੀ ਸੰਰਚਨਾ ਲਈ SSH ਟ੍ਰੈਫਿਕ ਦੀ ਆਗਿਆ ਦੇਣ ਲਈ, ਫਾਇਰਵਾਲ ਨਿਯਮ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਆਪਣੇ ਵਾਤਾਵਰਣ ਤੱਕ ਦਾ ਘੇਰਾ ਬਣਾਓ
--ਸਰੋਤ-ਰੇਂਜ ਪੈਰਾਮੀਟਰ। ਇਹ ਨਿਰਧਾਰਤ ਕਰਨ ਲਈ ਕਿ ਤੁਹਾਡੀ ਸੰਸਥਾ ਕਿਹੜੀਆਂ ਸਰੋਤ ਰੇਂਜਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੀ ਹੈ, ਤੁਹਾਨੂੰ ਆਪਣੀ ਨੈੱਟਵਰਕ ਟੀਮ ਨਾਲ ਕੰਮ ਕਰਨ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ

ਬਦਲੋ
ਤੁਹਾਡੇ ਆਪਣੇ IP ਐਡਰੈੱਸ ਸਕੋਪਾਂ ਨਾਲ:
IP_ADDRESS_SCOPE
gcloud compute firewall-rules create allow-ssh-$NAME_SUFFIX \ --network=network-$NAME_SUFFIX \ --direction=INGRESS \ --priority=1000 \ --action=ALLOW \ --rules=tcp:22 \ -- ਸਰੋਤ-ਰੇਂਜ =
IP_ADDRESS_SCOPE
 ਫਾਇਰਵਾਲ ਨਿਯਮ ਬਣਾਉਣ ਤੋਂ ਬਾਅਦ, ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਤਿੰਨ ਨਿਯਮ ਸ਼ਾਮਲ ਕੀਤੇ ਗਏ ਹਨ:
gcloud ਕੰਪਿਊਟ ਫਾਇਰਵਾਲ-ਨਿਯਮਾਂ ਦੀ ਸੂਚੀ \ --project=$PROJECT_ID \ --filter="NETWORK=network-$NAME_SUFFIX"ਹੇਠ ਦਿੱਤੀ ਉਦਾਹਰਨ ਆਉਟਪੁੱਟ ਦਰਸਾਉਂਦੀ ਹੈ ਕਿ ਤਿੰਨ ਨਿਯਮ ਸਹੀ ਢੰਗ ਨਾਲ ਬਣਾਏ ਗਏ ਹਨ:
NAME ਨੈੱਟਵਰਕ ਦਿਸ਼ਾ-ਨਿਰਦੇਸ਼ ਤਰਜੀਹ ਅਨੁਮਤੀ ਦਿਓ-ਸਿਹਤ-ਚੈੱਕ-ਐਪ ਨੈੱਟਵਰਕ-ਐਪ INGRESS 1000 tcp:80 ਅਨੁਮਤੀ-http-ਐਪ ਨੈੱਟਵਰਕ-ਐਪ INGRESS 1000 tcp:80 ਅਨੁਮਤੀ-ssh-ਐਪ ਨੈੱਟਵਰਕ-ਐਪ INGRESS 1000 tcp:22
## ਇੱਕ ਬੇਸ VM ਚਿੱਤਰ ਬਣਾਓ ਅਤੇ ਕੌਂਫਿਗਰ ਕਰੋ
ਸਮਾਨ VM ਬਣਾਉਣ ਲਈ ਜੋ ਤੁਸੀਂ ਵਾਧੂ ਸੰਰਚਨਾ ਤੋਂ ਬਿਨਾਂ ਤੈਨਾਤ ਕਰਦੇ ਹੋ, ਤੁਸੀਂ ਇੱਕ ਕਸਟਮ VM ਚਿੱਤਰ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋ। ਇਹ ਚਿੱਤਰ OS ਅਤੇ Apache ਸੰਰਚਨਾ ਨੂੰ ਕੈਪਚਰ ਕਰਦਾ ਹੈ, ਅਤੇ ਅਗਲੇ ਪੜਾਵਾਂ ਵਿੱਚ ਪ੍ਰਬੰਧਿਤ ਉਦਾਹਰਨ ਸਮੂਹ ਵਿੱਚ ਹਰੇਕ VM ਨੂੰ ਬਣਾਉਣ ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ

VM 'ਤੇ, ਤੁਸੀਂ ਇੱਕ ਬੁਨਿਆਦੀ ਬਣਾਉਂਦੇ ਹੋ
ਪਰਸਿਸਟੈਂਟ ਡਿਸਕ ਤੇ index.html ਫਾਈਲ ਅਤੇ
ਇਸ ਨੂੰ ਮਾਊਟ ਕਰੋ
/var/www/example.com. 'ਤੇ ਇੱਕ ਅਪਾਚੇ ਸੰਰਚਨਾ ਫਾਈਲ
/etc/apache2/sites-available/example.com.conf ਤੋਂ ਵੈੱਬ ਸਮੱਗਰੀ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ
ਮਾਊਂਟ ਕੀਤੀ ਸਥਿਰ ਡਿਸਕ ਟਿਕਾਣਾ

ਨਿਮਨਲਿਖਤ ਚਿੱਤਰ ਅਪਾਚੇ ਦੁਆਰਾ ਪ੍ਰਦਾਨ ਕੀਤੇ ਗਏ ਮੂਲ HTML ਪੰਨੇ ਨੂੰ ਦਿਖਾਉਂਦਾ ਹੈ ਜੋ ਕਿ ਸਥਿਰ ਡਿਸਕ 'ਤੇ ਸਟੋਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ:
ਤੁਸੀਂ ਹੇਠਾਂ ਦਿੱਤੇ ਕਦਮਾਂ ਵਿੱਚ ਇਸ ਵਾਤਾਵਰਣ ਨੂੰ ਬਣਾਉਂਦੇ ਹੋ

ਇੱਕ ਅਟੈਚਡ ਪਰਸਿਸਟੈਂਟ ਡਿਸਕ ਨਾਲ ਇੱਕ ਬੇਸ VM ਬਣਾਓ:
gcloud ਕੰਪਿਊਟ ਉਦਾਹਰਨਾਂ vm-base-$NAME_SUFFIX \ --zone=$ZONE \ --machine-type=n1-standard-1 \ --subnet=subnet-$NAME_SUFFIX-$REGION1 \ --tags=http-ਸਰਵਰ \ --image=debian-10-buster-v20210420 \ --image-project=debian-Cloud \ --boot-disk-size=10GB \ --boot-disk-type=pd-balanced \ --boot-disk- device-name=vm-base-$NAME_SUFFIX \ --create-disk=type=pd-ssd,name=disk-base-$NAME_SUFFIX,size=10GB,device-name=disk-base-$NAME_SUFFIX
ਤੁਸੀਂ VM ਨੂੰ ਨਾਮ ਦੇਣ ਅਤੇ ਸਹੀ ਸਬਨੈੱਟ ਨਾਲ ਜੁੜਨ ਲਈ ਇਸ ਦਸਤਾਵੇਜ਼ ਦੇ ਸ਼ੁਰੂ ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ ਪੈਰਾਮੀਟਰਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋ। ਬੂਟ ਡਿਸਕ ਅਤੇ ਡਾਟਾ ਡਿਸਕ ਲਈ ਪੈਰਾਮੀਟਰਾਂ ਤੋਂ ਨਾਮ ਵੀ ਨਿਰਧਾਰਤ ਕੀਤੇ ਗਏ ਹਨ

ਸਧਾਰਨ ਵੈੱਬਸਾਈਟ ਨੂੰ ਸਥਾਪਤ ਕਰਨ ਅਤੇ ਸੰਰਚਿਤ ਕਰਨ ਲਈ, ਪਹਿਲਾਂ SSH ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਬੇਸ VM ਨਾਲ ਜੁੜੋ:
gcloud ਕੰਪਿਊਟ ssh vm-base-$NAME_SUFFIX --zone=$ZONE
VM ਲਈ ਆਪਣੇ SSH ਸੈਸ਼ਨ ਵਿੱਚ, VM ਨੂੰ ਆਪਣੀ ਪਸੰਦ ਦੇ ਸੰਪਾਦਕ ਵਿੱਚ ਸੰਰਚਿਤ ਕਰਨ ਲਈ ਇੱਕ ਸਕ੍ਰਿਪਟ ਬਣਾਓ। ਹੇਠ ਦਿੱਤੀ ਉਦਾਹਰਨ ਨੈਨੋ ਨੂੰ ਸੰਪਾਦਕ ਵਜੋਂ ਵਰਤਦੀ ਹੈ:
nano configure-vm.
ਹੇਠ ਦਿੱਤੀ ਸੰਰਚਨਾ ਸਕ੍ਰਿਪਟ ਨੂੰ ਫਾਈਲ ਵਿੱਚ ਚਿਪਕਾਓ:
bin/bash NAME_SUFFIX=
app# ਮੂਲ ਵੈਬਸਾਈਟ ਫਾਈਲਾਂ ਲਈ ਡਾਇਰੈਕਟਰੀ ਬਣਾਓ sudo mkdir -p /var/www/example.com sudo chmod a+w /var/www/example.com sudo chown -R www-data: /var/www/example.com # ਡਿਸਕ ਦਾ ਨਾਮ ਲੱਭੋ, ਫਿਰ ਫਾਰਮੈਟ ਕਰੋ ਅਤੇ ਇਸਨੂੰ ਮਾਊਂਟ ਕਰੋ DISK_NAME="google-disk-base-$NAME_SUFFIX"DISK_PATH ਲੱਭੋ /dev/disk/by-id -name DISK_NAME}"| xargs -Ireadlink -fsudo mkfs.ext4 -m 0 - E lazy_itable_init=0,lazy_journal_init=0,Discard $DISK_PATH sudo mount -o discard,defaults $DISK_PATH /var/www/example.com # Apache sudo apt-ਅੱਪਡੇਟ ਇੰਸਟਾਲ ਕਰੋ&&  sudo apt-get -y install apache2 # ਮਾਊਂਟ ਕੀਤੀ ਪਰਸਿਸਟੈਂਟ ਡਿਸਕ sudo tee -a /var/www/example.com/index.html >/dev/null EOF'ਤੇ ਇੱਕ ਬੁਨਿਆਦੀ HTML ਫਾਈਲ ਲਿਖੋ।    HA / DR ਉਦਾਹਰਨ   
Cloud Storagep>
*:80> ServerName www.example.com ServerAdmin webmaster@localhost DocumentRoot /var/www/example.com ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined  EOF # ਅਪਾਚੇ ਸੰਰਚਨਾ ਫਾਈਲ ਨੂੰ ਸਮਰੱਥ ਬਣਾਓ ਅਤੇ ਸੇਵਾ ਨੂੰ ਰੀਲੋਡ ਕਰੋ sudo a2dissite 000-ਡਿਫਾਲਟ sudo a2ensite example.com.conf sudo systemctl reload apache2
ਨੂੰ ਅਪਡੇਟ ਕਰੋ
ਇਸ ਦਸਤਾਵੇਜ਼ ਦੇ ਸ਼ੁਰੂ ਵਿੱਚ ਸੈੱਟ ਕੀਤੇ ਮੁੱਲ ਨਾਲ ਮੇਲ ਕਰਨ ਲਈ ਵੇਰੀਏਬਲ, ਜਿਵੇਂ ਕਿ
NAME_SUFFIX ਐਪ

ਫਾਈਲ ਨੂੰ ਲਿਖੋ ਅਤੇ ਆਪਣੇ ਸੰਪਾਦਕ ਤੋਂ ਬਾਹਰ ਜਾਓ। ਉਦਾਹਰਨ ਲਈ, ਨੈਨੋ ਵਿੱਚ ਤੁਸੀਂ ਵਰਤਦੇ ਹੋ
Ctrl-Oto ਫਾਈਲ ਨੂੰ ਲਿਖੋ, ਫਿਰ ਇਸ ਨਾਲ ਬਾਹਰ ਜਾਓ
Ctrl-X

ਸੰਰਚਨਾ ਸਕ੍ਰਿਪਟ ਨੂੰ ਚੱਲਣਯੋਗ ਬਣਾਓ, ਫਿਰ ਇਸਨੂੰ ਚਲਾਓ:
chmod +x configure-vm../configure-vm.
VM ਲਈ SSH ਸੈਸ਼ਨ ਤੋਂ ਬਾਹਰ ਜਾਓ:
ਨਿਕਾਸ
VM ਦਾ IP ਪਤਾ ਪ੍ਰਾਪਤ ਕਰੋ ਅਤੇ ਵਰਤੋਂ ਕਰੋ
ਮੂਲ ਵੈੱਬ ਪੇਜ ਦੇਖਣ ਲਈ ਕਰਲ ਕਰੋ:
curl $(gcloud ਕੰਪਿਊਟ ਉਦਾਹਰਨਾਂ vm-base-$NAME_SUFFIX \ --zone $ZONE \ --format="value(networkInterfaces.accessConfigs[0].natIP ਦਾ ਵਰਣਨ ਕਰਦੀਆਂ ਹਨ)
ਮੁੱਢਲੀ ਵੈੱਬਸਾਈਟ ਨੂੰ ਵਾਪਸ ਕਰ ਦਿੱਤਾ ਗਿਆ ਹੈ, ਜਿਵੇਂ ਕਿ ਹੇਠਾਂ ਦਿੱਤੀ ਉਦਾਹਰਨ ਆਉਟਪੁੱਟ ਵਿੱਚ ਦਿਖਾਇਆ ਗਿਆ ਹੈ:
    HA / DR ਉਦਾਹਰਨ   
Cloud Storagep>

# ਬੇਸ VM ਚਿੱਤਰ ਬਣਾਓ gcloud compute images create image-$NAME_SUFFIX \ --source-disk=vm-base-$NAME_SUFFIX \ --source-disk-zone=$ZONE gcloud ਕੰਪਿਊਟ ਚਿੱਤਰ ਚਿੱਤਰ-ਡਿਸਕ-$NAME_SUFFIX ਬਣਾਓ। -source-disk=disk-base-$NAME_SUFFIX\ --source-disk-zone=$ZONE # ਇੰਸਟੈਂਸ ਟੈਂਪਲੇਟ ਬਣਾਓ gcloud compute instance-templates create template-$NAME_SUFFIX-$REGION1\ --machine-type=n1-standard- 1 \ --subnet=projects/$PROJECT_ID/regions/$REGION1/subnetworks/subnet-$NAME_SUFFIX-$REGION1 \ --region=$REGION1 \ --tags=http-ਸਰਵਰ \ --metadatastartup-script /bin/bashn 'echo\ UUIDblkid\ -s\ UUID\ -o\ value\ /dev/sdb /var/www/example.com\ ext4\ discard,defaults,nofail\ 0\ 2 ee\ -a\ /etc/fstabn'mount \ -a \ --image=image-$NAME_SUFFIX \ --create-disk=image=image-disk-$NAME_SUFFIX,auto-delete=yes gcloud compute instance-templates create template-$NAME_SUFFIX-$REGION2 \ --machine -type=n1-ਸਟੈਂਡਰਡ-1 \ --subnet=projects/$PROJECT_ID/regions/$REGION2/subnetworks/subnet-$NAME_SUFFIX-$REGION2 \ --region=$REGION2 \ --tags=http-ਸਰਵਰ \ --metadatastartup-script /bin/bashn'echo\ UUIDblkid\ -s\ UUID\ -o\ value\ /dev/sdb /var/www/example.com\ ext4\ discard,defaults ,nofail\ 0\ 2 ee\ -a\ /etc/fstabn'mount\ -a \ --image=image-$NAME_SUFFIX \ --create-disk=image=image-disk-$NAME_SUFFIX,auto-delete=yes # VM ਉਦਾਹਰਨਾਂ ਲਈ ਇੱਕ ਸਿਹਤ ਜਾਂਚ ਬਣਾਓ \ --template=template-$NAME_SUFFIX-$REGION1 \ --size=2 \ --region=$REGION1 \ --health-check=http-basic-check-$NAME_SUFFIX gcloud compute instance-groups ਪ੍ਰਬੰਧਿਤ instance-group ਬਣਾਓ -$NAME_SUFFIX-$REGION2 \ --template=template-$NAME_SUFFIX-$REGION2 \ --size=2 \ --region=$REGION2 \ --health-check=http-basic-check-$NAME_SUFFIX
## ਇੱਕ ਲੋਡ ਬੈਲੈਂਸਰ ਬਣਾਓ ਅਤੇ ਕੌਂਫਿਗਰ ਕਰੋ
ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਤੁਹਾਡੀ ਵੈਬਸਾਈਟ ਤੱਕ ਪਹੁੰਚ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਪ੍ਰਬੰਧਿਤ ਉਦਾਹਰਨ ਸਮੂਹਾਂ ਵਿੱਚ ਚੱਲਣ ਵਾਲੇ VM ਤੱਕ ਟ੍ਰੈਫਿਕ ਦੀ ਆਗਿਆ ਦੇਣ ਦੀ ਲੋੜ ਹੈ। ਜੇਕਰ ਕਿਸੇ ਪ੍ਰਬੰਧਿਤ ਉਦਾਹਰਨ ਸਮੂਹ ਵਿੱਚ ਕੋਈ ਜ਼ੋਨ ਅਸਫਲਤਾ ਹੈ ਤਾਂ ਤੁਸੀਂ ਨਵੇਂ VM 'ਤੇ ਟ੍ਰੈਫਿਕ ਨੂੰ ਸਵੈਚਲਿਤ ਤੌਰ 'ਤੇ ਰੀਡਾਇਰੈਕਟ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ

ਹੇਠਾਂ ਦਿੱਤੇ ਭਾਗ ਵਿੱਚ, ਤੁਸੀਂ ਪੋਰਟ 80 'ਤੇ HTTP ਟ੍ਰੈਫਿਕ ਲਈ ਇੱਕ ਬੈਕਐਂਡ ਸੇਵਾ ਦੇ ਨਾਲ ਇੱਕ ਬਾਹਰੀ HTTPS ਲੋਡ ਬੈਲੈਂਸਰ ਬਣਾਉਂਦੇ ਹੋ, ਪਿਛਲੇ ਪੜਾਵਾਂ ਵਿੱਚ ਬਣਾਈ ਗਈ ਸਿਹਤ ਜਾਂਚ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋ, ਅਤੇ ਬੈਕਐਂਡ ਸੇਵਾ ਦੇ ਰਾਹੀਂ ਇੱਕ ਬਾਹਰੀ IP ਐਡਰੈੱਸ ਨੂੰ ਮੈਪ ਕਰਦੇ ਹੋ।

ਵਧੇਰੇ ਜਾਣਕਾਰੀ ਲਈ, ਇੱਕ ਸਧਾਰਨ ਬਾਹਰੀ HTTP ਲੋਡ ਬੈਲੇਂਸਰ ਨੂੰ ਕਿਵੇਂ ਸੈਟ ਅਪ ਕਰਨਾ ਹੈ ਦੇਖੋ

ਆਪਣੀ ਐਪਲੀਕੇਸ਼ਨ ਲਈ ਲੋਡ ਬੈਲੇਂਸਰ ਬਣਾਓ ਅਤੇ ਕੌਂਫਿਗਰ ਕਰੋ:
# HTTP ਪੋਰਟ 80 ਲਈ ਪੋਰਟ ਨਿਯਮਾਂ ਦੀ ਸੰਰਚਨਾ ਕਰੋ name-ports \ instance-group-$NAME_SUFFIX-$REGION2 \ --named-ports http:80 \ --region $REGION2 # ਇੱਕ ਬੈਕਐਂਡ ਸੇਵਾ ਬਣਾਓ ਅਤੇ ਇਸ ਵਿੱਚ ਪ੍ਰਬੰਧਿਤ ਇੰਸਟੈਂਸ ਗਰੁੱਪ ਸ਼ਾਮਲ ਕਰੋ gcloud compute backend-services create \ web- backend-service-$NAME_SUFFIX \ --protocol=HTTP \ --port-name=http \ --health-checks=http-basic-check-$NAME_SUFFIX \ --global gcloud compute backend-services add-backend \ web- backend-service-$NAME_SUFFIX \ --instance-group=instance-group-$NAME_SUFFIX-$REGION1 \ --instance-group-region=$REGION1 \ --global gcloud compute backend-services add-backend \ web-backend- service-$NAME_SUFFIX \ --instance-group=instance-group-$NAME_SUFFIX-$REGION2 \ --instance-group-region=$REGION2 \ --global # ਬੈਕਐਂਡ ਸੇਵਾ ਲਈ ਇੱਕ URL ਨਕਸ਼ਾ ਬਣਾਓ gcloud compute url-maps create web-map-http-$NAME_SUFFIX \ --default-service web-backend-service-$NAME_SUFFIX # HTTP ਟ੍ਰੈਫਿਕ ਲਈ ਅੱਗੇ ਭੇਜਣ ਦੀ ਸੰਰਚਨਾ ਕਰੋ gcloud compute target-http-proxies create \ http-lb-proxy-$NAME_SUFFIX \ --url-map web-map-http- $NAME_SUFFIX gcloud compute forwarding-rules create \ http-content-rule-$NAME_SUFFIX \ --global \ --target-http-proxy=http-lb-proxy-$NAME_SUFFIX \ --ports=80
ਵੈੱਬ ਟ੍ਰੈਫਿਕ ਲਈ ਫਾਰਵਰਡਿੰਗ ਨਿਯਮ ਦਾ IP ਪਤਾ ਪ੍ਰਾਪਤ ਕਰੋ:
IP_ADDRESSgcloud ਕੰਪਿਊਟ ਫਾਰਵਰਡਿੰਗ-ਨਿਯਮ http-content-rule-$NAME_SUFFIX \ --global \ --format="value(IPAddress) ਦਾ ਵਰਣਨ ਕਰਦੇ ਹਨ
ਵਰਤੋ
ਪਿਛਲੇ ਪਗ ਤੋਂ ਲੋਡ ਬੈਲੈਂਸਰ ਦੇ IP ਐਡਰੈੱਸ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਵੈੱਬਸਾਈਟ ਦੇਖਣ ਲਈ, curl, ਜਾਂ ਆਪਣਾ ਵੈਬ ਬ੍ਰਾਊਜ਼ਰ ਖੋਲ੍ਹੋ:
ਕਰਲ $IP_ADDRESS
ਲਈ ਗਰਮ ਫੇਲਓਵਰ ਵਾਲੀ ਕੰਪਿਊਟ ਇੰਜਣ ਵੈੱਬਸਾਈਟ 'ਤੇ ਤੁਹਾਡਾ ਸੁਆਗਤ ਹੈ। ਇੱਕ HTTP 404 ਗਲਤੀ ਵਾਪਸ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਜੇਕਰ ਲੋਡ ਬੈਲੇਂਸਰ ਅਜੇ ਵੀ ਤੈਨਾਤ ਕਰ ਰਿਹਾ ਹੈ। ਜੇ ਲੋੜ ਹੋਵੇ, ਤਾਂ ਕੁਝ ਮਿੰਟਾਂ ਦੀ ਉਡੀਕ ਕਰੋ ਅਤੇ ਦੁਬਾਰਾ ਵੈੱਬਸਾਈਟ ਤੱਕ ਪਹੁੰਚ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋ

ਮੁੱਢਲੀ ਵੈੱਬਸਾਈਟ ਨੂੰ ਵਾਪਸ ਕਰ ਦਿੱਤਾ ਗਿਆ ਹੈ, ਜਿਵੇਂ ਕਿ ਹੇਠਾਂ ਦਿੱਤੀ ਉਦਾਹਰਨ ਆਉਟਪੁੱਟ ਵਿੱਚ ਦਿਖਾਇਆ ਗਿਆ ਹੈ:
    HA / DR ਉਦਾਹਰਨ   
Cloud Storagep>
< index.html     HA / DR example   
Welcome to a test static web server with warm failover from Cloud Storagep> 

example.com
Get the details of the Cloud DNS zone:
gcloud dns managed-zones describe zone-$NAME_SUFFIX
The following example output shows the
nameServersfor the zone, such as
ns-cloud-b1.googledomains.com

 kind: dns#managedZone name: zone-app nameServers: - ns-cloud-b1.googledomains.com. - ns-cloud-b2.googledomains.com. - ns-cloud-b3.googledomains.com. - ns-cloud-b4.googledomains.com

Cloud DNS must be authoritative for your domain. Create nameserver (NS) records with your domain registrar that point to your Cloud DNS zone. Use the nameserver addresses returned in the previous step

For more information and an example using Google Domains, see How to update name servers

In your Cloud DNS zone, add a record for
wwwusing the load balancer IP address obtained in a previous section:
gcloud dns record-sets transaction start \ --zone=zone-$NAME_SUFFIX gcloud dns record-sets transaction add $IP_ADDRESS \ --name=www.$DOMAIN \ --ttl=300 \ --type=A \ --zone=zone-$NAME_SUFFIX
This record directs user requests for the website through the load balancer to the managed instance groups. A TTL of 300 seconds is set to reduce the length of time the cached DNS record exists for a user

Create a record to be used by the Cloud Storage bucket for the static website:
gcloud dns record-sets transaction add c.storage.googleapis.com. \ --name=static-web.$DOMAIN \ --ttl=300 \ --type=CNAME \ --zone=zone-$NAME_SUFFIX
This example uses
static-webas the subdomain. Leave the
c.storage.googleapis.com.Again, a TTL of 300 seconds is set to reduce the length of time the cached DNS record exists for a user
Finally,the DNS record additions to the zone:
gcloud dns record-sets transaction execute \ --zone=zone-$NAME_SUFFIX
## Verify and test the DNS zone and records
Let's review the resource deployments before simulating a zone failure. All of the resources have been created to support the environment, as shown in the following image:
- Cloud DNS zone records direct users to the load balancer for distribution across the managed instance group VMs

- A Cloud Storage bucket is configured to host static web pages if there's an outage with the managed instance groups

- The Cloud DNS zone is configured to use the static site in Cloud Storage, but doesn't currently resolve requests to the storage bucket

To view the DNS records and test resolution, you must resolve addresses against the Cloud DNS servers. In production deployments, make sure you test and verify the addresses resolve correctly, then update your own DNS servers to resolve appropriately. This document doesn't detail the steps to update your own DNS servers, only how to verify traffic flows correctly under normal and failover conditions

Get the details of the Cloud DNS zone again:
gcloud dns managed-zones describe zone-$NAME_SUFFIX
The following example output shows the
nameServersfor the zone, such as
ns-cloud-b1.googledomains.com

 kind: dns#managedZone name: zone-app nameServers: - ns-cloud-b1.googledomains.com. - ns-cloud-b2.googledomains.com. - ns-cloud-b3.googledomains.com. - ns-cloud-b4.googledomains.com

To resolve the
wwwrecord for your Cloud DNS zone against one of these name servers, use the
digcommand:
dig @ns-cloud-b1.googledomains.com www.$DOMAIN
This example uses the
ns-cloud-b1.googledomains.comnameserver address returned from the previous
describecommand. Provide your own nameserver address shown in the output of the previous command
The following example output shows that the record resolves to the IP address of the load balancer. If you used this nameserver to access the address, such as using
curland the
--resolveparameter with the Cloud DNS nameserver, the default page would be displayed from one of the managed instance groups behind the load balancer

;DiG [email protected] www.example.com ; (1 server found);; QUESTION SECTION: ;www.example.com. IN A ;; ANSWER SECTION: www.example.com. 300 IN A 35.227.253.90
Use the
digcommand again to verify the DNS record for the static website in Cloud Storage:
dig @ns-cloud-b1.googledomains.com static-web.$DOMAIN
The following example output shows that the record resolves to Cloud Storage that can serve the static content from the storage bucket:
;DiG [email protected] static-web.example.com ; (1 server found);; QUESTION SECTION: ;static-web.example.com. IN A ;; ANSWER SECTION: static-web.example.com. 300 IN CNAME c.storage.googleapis.com

## Fail over to the Cloud Storage bucket
In a production environment, you might get an alert using Cloud Monitoring or other monitoring solution when there's a problem with the managed instance groups. This alert prompts a human to understand the scope of the failure before you update the Cloud DNS records to redirect traffic to the Cloud Storage-hosted static website. An alternative approach is to use your monitoring solution to automatically respond to outages with the managed instance groups

When you fail over, Cloud DNS resolves traffic to the Cloud Storage-hosted static website, as shown in the following image:
When you or your monitoring solution determine the most appropriate action

is to update the Cloud DNS records to direct traffic to Cloud Storage,
update the existing DNS
A record. In this document, you manually update the
Cloud DNS records to redirect traffic to the Cloud Storage-hosted
static website

To fail over the Cloud DNS records, remove the existing
Arecord that resolves to the load balancer:
gcloud dns record-sets transaction start \ --zone=zone-$NAME_SUFFIX gcloud dns record-sets transaction remove $IP_ADDRESS \ --name=www.$DOMAIN \ --ttl=300 \ --type=A \ --zone=zone-$NAME_SUFFIX
Create a
CNAMErecord for
wwwthat points to the Cloud Storage-hosted content:
gcloud dns record-sets transaction add static-web.$DOMAIN \ --name=www.$DOMAIN. \ --ttl=30 \ --type=CNAME \ --zone=zone-$NAME_SUFFIX
the updates to the Cloud DNS zone:
gcloud dns record-sets transaction execute \ --zone=zone-$NAME_SUFFIX
Use the
digcommand to confirm the
wwwrecord now resolves to the address of the Cloud Storage static website:
dig @ns-cloud-b1.googledomains.com www.$DOMAIN
The following example output shows that the
www.example.comrecord resolves to the CNAME record of the Cloud Storage static website. Requests to access
www.example.comare redirected to the Cloud Storage bucket, which displays the static website:
;DiG [email protected] www.example.com ; (1 server found);; QUESTION SECTION: ;www.example.com. IN A ;; ANSWER SECTION: www.example.com. 30 IN CNAME static-web.example.com. static-web.example.com. 300 IN CNAME c.storage.googleapis.com

## Fail back to the managed instance groups
After issues with the managed instance groups are resolved, you can fail back to serving content from the load-balanced managed instance groups by updating the Cloud DNS records again. Again, a human might make this decision using Cloud Monitoring insights for the health of the managed instance groups. Or, you could use automation to respond to the restored health of the managed instance group. In this document, you manually update the Cloud DNS records

When you fail back, Cloud DNS resolves traffic to the managed instance groups again, as shown in the following image:
Remove the
wwwCNAME record that redirects traffic to the Cloud Storage-hosted content:
gcloud dns record-sets transaction start \ --zone=zone-$NAME_SUFFIX gcloud dns record-sets transaction remove static-web.$DOMAIN \ --name=www.$DOMAIN \ --ttl=30 \ --type=CNAME \ --zone=zone-$NAME_SUFFIX
Add an
Arecord to point to the load balancer in front of the managed instance groups again:

gcloud dns record-sets transaction add $IP_ADDRESS \ --name=www.$DOMAIN \ --ttl=300 \ --type=A \ --zone=zone-$NAME_SUFFIX
the updates to the Cloud DNS zone:
gcloud dns record-sets transaction execute \ --zone=zone-$NAME_SUFFIX
Use the
digcommand one more time to confirm the
wwwrecord resolves to the address of the load balancer in front of the managed instance groups again:
dig @ns-cloud-b1.googledomains.com www.$DOMAIN
The following example output shows that the record resolves to the IP address of the load balancer and traffic would be served from one of the managed instance groups:
;DiG [email protected] www.example.com ; (1 server found);; QUESTION SECTION: ;www.example.com. IN A ;; ANSWER SECTION: www.example.com. 300 IN A 35.227.253.90
## Clean up
To avoid incurring charges to your Google Cloud account for the resources used in this tutorial, either delete the project that contains the resources, or keep the project and delete the individual resources

To delete the individual resources created in this document, complete the following steps:
Delete the DNS zone and records:
touch empty-file gcloud dns record-sets import -z zone-$NAME_SUFFIX \ --delete-all-existing \ empty-file rm empty-file gcloud dns managed-zones delete zone-$NAME_SUFFIX
Delete the Cloud Storage bucket:
gsutil rm -r gsstatic-web.$DOMAIN
Delete the load balancer configuration:
gcloud compute forwarding-rules delete \ http-content-rule-$NAME_SUFFIX --global --quiet gcloud compute target-http-proxies delete \ http-lb-proxy-$NAME_SUFFIX --quiet gcloud compute url-maps delete web-map-http-$NAME_SUFFIX --quiet gcloud compute backend-services delete \ web-backend-service-$NAME_SUFFIX --global --quiet
Delete the managed instance groups and health check:
gcloud compute instance-groups managed delete \ instance-group-$NAME_SUFFIX-$REGION1 \ --region=$REGION1 --quiet gcloud compute instance-groups managed delete \ instance-group-$NAME_SUFFIX-$REGION2 \ --region=$REGION2 --quiet gcloud compute health-checks delete http-basic-check-$NAME_SUFFIX --quiet
Delete the instance templates, images, base VM, and persistent disks:
gcloud compute instance-templates delete \ template-$NAME_SUFFIX-$REGION1 --quiet gcloud compute instance-templates delete \ template-$NAME_SUFFIX-$REGION2 --quiet gcloud compute images delete image-$NAME_SUFFIX --quiet gcloud compute images delete image-disk-$NAME_SUFFIX --quiet gcloud compute instances delete vm-base-$NAME_SUFFIX \ --zone=$ZONE --quiet
Delete the firewall rules


gcloud compute firewall-rules delete \ allow-health-check-$NAME_SUFFIX --quiet gcloud compute firewall-rules delete \ allow-ssh-$NAME_SUFFIX --quiet gcloud compute firewall-rules delete \ allow-http-$NAME_SUFFIX --quiet
Delete the subnet and VPC

gcloud compute networks subnets delete \ subnet-$NAME_SUFFIX-$REGION1 --region=$REGION1 --quiet gcloud compute networks subnets delete \ subnet-$NAME_SUFFIX-$REGION2 --region=$REGION2 --quiet gcloud compute networks delete network-$NAME_SUFFIX --quiet
## What's next
- For an alternative approach that uses external HTTP(S) Load Balancing instead of Cloud DNS to control the failover, see Deploy a warm recoverable web server with Compute Engine and Cloud Storage. This pattern is useful if you don't have, or don't want to use, Cloud DNS

- To learn how how to determine the best approach for your own applications and which recovery method to use, see the Disaster recovery planning guide

- To see other patterns for applications, such as cold and hot failover, see Disaster recovery scenarios for applications

- For more ways to handle scale and availability, see the Patterns for scalable and resilient apps

- Explore reference architectures, diagrams, tutorials, and best practices about Google Cloud. Take a look at our Cloud Architecture Center.