У цій статті ми за допомогою , , и організуємо безшовну викладку веб-програми. — це техніка, що дозволяє миттєво оновлювати програму, не відхиляючи жодного запиту. Вона є однією із стратегій zero downtime deployment і найкраще підходить для додатків з одним інстансом, але можливістю завантажити поруч другий, готовий до роботи інстанс.
Припустимо, у Вас є веб-додаток, з яким активно працює безліч клієнтів, і йому зовсім не можна на кілька секунд прилягти. Вам дуже потрібно викотити оновлення бібліотеки, фікс бага або нову круту фічу. У звичайній ситуації потрібно зупинити додаток, замінити його і знову запустити. У випадку докера, можна спочатку замінити, потім перезапустити, але все одно буде період, в якому запити до додатку не опрацюються, адже зазвичай додатку потрібно деякий час на початкове завантаження. А якщо воно запуститься, але виявиться непрацездатним? Ось таке завдання, давайте її вирішувати мінімальними засобами та максимально елегантно.
DISCLAIMER: Більшість статті представлено в експериментальному форматі - у вигляді запису консольної сесії. Сподіваюся, це буде не дуже складно сприймати і цей код сам себе документує в достатньому обсязі. Для атмосферності, уявіть, що це не просто кодсніпети, а папір із «залізного» телетайпу.
Цікаві техніки, які складно нагуглити просто читаючи код описані на початку кожного розділу. Якщо буде незрозуміло ще щось — гуглить і перевіряйте в (Благо, він знову працює, у зв'язку з розблокуванням телеграма). Що не гуглиться — питайте у коментах. Із задоволенням доповню відповідний розділ «Цікаві техніки».
Приступимо.
$ mkdir blue-green-deployment && cd $_Сервіс
Зробимо піддослідний сервіс та помістимо його у контейнер.
Цікаві техніки
cat << EOF > file-name( + ) - спосіб створити багаторядковий файл однією командою. Все, що bash прочитає з/dev/stdinпісля цього рядка і до рядкаEOFбуде записано вfile-name.wget -qO- URL() - вивести отриманий по HTTP документ в/dev/stdout(аналогcurl URL).
Роздруківка
Я спеціально розриваю сніпет, щоб увімкнути підсвічування для Python. Наприкінці буде ще один такий шматок. Вважайте, що у цих місцях папір розрізали для передачі у відділ хайлайтингу (де код розфарбовували вручну хайлайтерами), та був ці шматки вклеїли назад.
$ cat << EOF > uptimer.pyfrom http.server import BaseHTTPRequestHandler, HTTPServer
from time import monotonic
app_version = 1
app_name = f'Uptimer v{app_version}.0'
loading_seconds = 15 - app_version * 5
class Handler(BaseHTTPRequestHandler):
def do_GET(self):
if self.path == '/':
try:
t = monotonic() - server_start
if t < loading_seconds:
self.send_error(503)
else:
self.send_response(200)
self.send_header('Content-Type', 'text/html')
self.end_headers()
response = f'<h2>{app_name} is running for {t:3.1f} seconds.</h2>n'
self.wfile.write(response.encode('utf-8'))
except Exception:
self.send_error(500)
else:
self.send_error(404)
httpd = HTTPServer(('', 8080), Handler)
server_start = monotonic()
print(f'{app_name} (loads in {loading_seconds} sec.) started.')
httpd.serve_forever()EOF
$ cat << EOF > Dockerfile
FROM python:alpine
EXPOSE 8080
COPY uptimer.py app.py
CMD [ "python", "-u", "./app.py" ]
EOF
$ docker build --tag uptimer .
Sending build context to Docker daemon 39.42kB
Step 1/4 : FROM python:alpine
---> 8ecf5a48c789
Step 2/4 : EXPOSE 8080
---> Using cache
---> cf92d174c9d3
Step 3/4 : COPY uptimer.py app.py
---> a7fbb33d6b7e
Step 4/4 : CMD [ "python", "-u", "./app.py" ]
---> Running in 1906b4bd9fdf
Removing intermediate container 1906b4bd9fdf
---> c1655b996fe8
Successfully built c1655b996fe8
Successfully tagged uptimer:latest
$ docker run --rm --detach --name uptimer --publish 8080:8080 uptimer
8f88c944b8bf78974a5727070a94c76aa0b9bb2b3ecf6324b784e782614b2fbf
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
8f88c944b8bf uptimer "python -u ./app.py" 3 seconds ago Up 5 seconds 0.0.0.0:8080->8080/tcp uptimer
$ docker logs uptimer
Uptimer v1.0 (loads in 10 sec.) started.
$ wget -qSO- http://localhost:8080
HTTP/1.0 503 Service Unavailable
Server: BaseHTTP/0.6 Python/3.8.3
Date: Sat, 22 Aug 2020 19:52:40 GMT
Connection: close
Content-Type: text/html;charset=utf-8
Content-Length: 484
$ wget -qSO- http://localhost:8080
HTTP/1.0 200 OK
Server: BaseHTTP/0.6 Python/3.8.3
Date: Sat, 22 Aug 2020 19:52:45 GMT
Content-Type: text/html
<h2>Uptimer v1.0 is running for 15.4 seconds.</h2>
$ docker rm --force uptimer
uptimerРеверс-проксі
Щоб наш додаток мав можливість непомітно змінитись, необхідно, щоб перед ним була ще якась сутність, яка приховає його підміну. Це може бути веб-сервер в . Реверс-проксі встановлюється між клієнтом та програмою. Він приймає запити від клієнтів і перенаправляє їх у додаток, а відповіді програми надсилає клієнтам.
Додаток та реверс-проксі можна зв'язати всередині докеру за допомогою . Таким чином, контейнеру з додатком можна навіть не прокидати порт у хост-системі, це дозволяє максимально ізолювати додаток від загроз із зовнішності.
Якщо реверс-проксі житиме на іншому хості, доведеться відмовитися від docker network і зв'язати програму з реверс-проксі через мережу хоста, прокинувши порт додатки параметром --publish, як при першому запуску та як у реверс-проксі.
Реверс-проксі запускатимемо на порту 80, бо це саме та сутність, якою слід слухати зовнішню. Якщо 80-й порт у Вас на тестовому хості зайнятий, поміняйте параметр --publish 80:80 на --publish ANY_FREE_PORT:80.
Цікаві техніки
- «У docker-мережах, створених користувачем, з контейнерами можна зв'язуватися не лише за адресою IP. Ім'я контейнера також резолвується в його IP-адресу» (, пункт 5 докер-кодексу).
Роздруківка
$ docker network create web-gateway
5dba128fb3b255b02ac012ded1906b7b4970b728fb7db3dbbeccc9a77a5dd7bd
$ docker run --detach --rm --name uptimer --network web-gateway uptimer
a1105f1b583dead9415e99864718cc807cc1db1c763870f40ea38bc026e2d67f
$ docker run --rm --network web-gateway alpine wget -qO- http://uptimer:8080
<h2>Uptimer v1.0 is running for 11.5 seconds.</h2>
$ docker run --detach --publish 80:80 --network web-gateway --name reverse-proxy nginx:alpine
80695a822c19051260c66bf60605dcb4ea66802c754037704968bc42527bf120
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
80695a822c19 nginx:alpine "/docker-entrypoint.…" 27 seconds ago Up 25 seconds 0.0.0.0:80->80/tcp reverse-proxy
a1105f1b583d uptimer "python -u ./app.py" About a minute ago Up About a minute 8080/tcp uptimer
$ cat << EOF > uptimer.conf
server {
listen 80;
location / {
proxy_pass http://uptimer:8080;
}
}
EOF
$ docker cp ./uptimer.conf reverse-proxy:/etc/nginx/conf.d/default.conf
$ docker exec reverse-proxy nginx -s reload
2020/06/23 20:51:03 [notice] 31#31: signal process started
$ wget -qSO- http://localhost
HTTP/1.1 200 OK
Server: nginx/1.19.0
Date: Sat, 22 Aug 2020 19:56:24 GMT
Content-Type: text/html
Transfer-Encoding: chunked
Connection: keep-alive
<h2>Uptimer v1.0 is running for 104.1 seconds.</h2>Безшовні деплоймент
Викотимо нову версію програми (з дворазовим бустом startup performance) і спробуємо її задеплоїти безшовно.
Цікаві техніки
echo 'my text' | docker exec -i my-container sh -c 'cat > /my-file.txt'- Записати текстmy textу файл/my-file.txtусередині контейнераmy-container.cat > /my-file.txt— Записати у файл вміст стандартного входу/dev/stdin.
Роздруківка
$ sed -i "s/app_version = 1/app_version = 2/" uptimer.py
$ docker build --tag uptimer .
Sending build context to Docker daemon 39.94kB
Step 1/4 : FROM python:alpine
---> 8ecf5a48c789
Step 2/4 : EXPOSE 8080
---> Using cache
---> cf92d174c9d3
Step 3/4 : COPY uptimer.py app.py
---> 3eca6a51cb2d
Step 4/4 : CMD [ "python", "-u", "./app.py" ]
---> Running in 8f13c6d3d9e7
Removing intermediate container 8f13c6d3d9e7
---> 1d56897841ec
Successfully built 1d56897841ec
Successfully tagged uptimer:latest
$ docker run --detach --rm --name uptimer_BLUE --network web-gateway uptimer
96932d4ca97a25b1b42d1b5f0ede993b43f95fac3c064262c5c527e16c119e02
$ docker logs uptimer_BLUE
Uptimer v2.0 (loads in 5 sec.) started.
$ docker run --rm --network web-gateway alpine wget -qO- http://uptimer_BLUE:8080
<h2>Uptimer v2.0 is running for 23.9 seconds.</h2>
$ sed s/uptimer/uptimer_BLUE/ uptimer.conf | docker exec --interactive reverse-proxy sh -c 'cat > /etc/nginx/conf.d/default.conf'
$ docker exec reverse-proxy cat /etc/nginx/conf.d/default.conf
server {
listen 80;
location / {
proxy_pass http://uptimer_BLUE:8080;
}
}
$ docker exec reverse-proxy nginx -s reload
2020/06/25 21:22:23 [notice] 68#68: signal process started
$ wget -qO- http://localhost
<h2>Uptimer v2.0 is running for 63.4 seconds.</h2>
$ docker rm -f uptimer
uptimer
$ wget -qO- http://localhost
<h2>Uptimer v2.0 is running for 84.8 seconds.</h2>
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
96932d4ca97a uptimer "python -u ./app.py" About a minute ago Up About a minute 8080/tcp uptimer_BLUE
80695a822c19 nginx:alpine "/docker-entrypoint.…" 8 minutes ago Up 8 minutes 0.0.0.0:80->80/tcp reverse-proxyНа даному етапі образ білдиться прямо на сервері, що вимагає наявності там вихідних програм, а також навантажує сервер зайвою роботою. Наступним кроком буде виділення складання образу на окрему машину (наприклад, CI-систему) з подальшою передачею його на сервер.
Перекачування образів
На жаль, перекачувати образи з localhost на localhost не має сенсу, тому цей розділ можна помацати тільки маючи під рукою два хоста з докером. На мінімалках це виглядає приблизно так:
$ ssh production-server docker image ls
REPOSITORY TAG IMAGE ID CREATED SIZE
$ docker image save uptimer | ssh production-server 'docker image load'
Loaded image: uptimer:latest
$ ssh production-server docker image ls
REPOSITORY TAG IMAGE ID CREATED SIZE
uptimer latest 1d56897841ec 5 minutes ago 78.9MBКоманда docker save зберігає дані образу в .tar архів, тобто він важить приблизно в 1.5 рази більше, ніж міг би важити в стислому вигляді. Так потиснемо ж його в ім'я економії часу та трафіку:
$ docker image save uptimer | gzip | ssh production-server 'zcat | docker image load'
Loaded image: uptimer:latestА ще, можна спостерігати за процесом перекачування (щоправда, для цього потрібна стороння утиліта):
$ docker image save uptimer | gzip | pv | ssh production-server 'zcat | docker image load'
25,7MiB 0:01:01 [ 425KiB/s] [ <=> ]
Loaded image: uptimer:latestПорада: Якщо Вам для з'єднання з сервером SSH потрібна купа параметрів, можливо ви не використовуєте файл
~/.ssh/config.
Передача образу через docker image save/load — це наймінімалістичніший метод, але не єдиний. Є й інші:
- Container Registry (стандарт галузі).
- Підключитися до docker daemon сервера з іншого хоста:
- Змінне середовище
DOCKER_HOST. - Параметр командного рядка
-Hабо--hostінструментуdocker-compose. docker context
- Змінне середовище
Другий спосіб (з трьома варіантами його реалізації) добре описаний у статті .
deploy.sh
Тепер зберемо все, що ми вручну робили в один скрипт. Почнемо з top-level функції, а потім подивимося на інші, які у ній.
Цікаві техніки
${parameter?err_msg}- одне із заклинань bash-магії (aka ). якщоparameterне заданий, вивестиerr_msgта вийти з кодом 1.docker --log-driver journald— драйвером логування докера є текстовий файл без будь-якої ротації. З таким підходом логи швидко забивають весь диск, тому для production-оточення необхідно міняти драйвер на розумніший.
Скрипт деплойменту
deploy() {
local usage_msg="Usage: ${FUNCNAME[0]} image_name"
local image_name=${1?$usage_msg}
ensure-reverse-proxy || return 2
if get-active-slot $image_name
then
local OLD=${image_name}_BLUE
local new_slot=GREEN
else
local OLD=${image_name}_GREEN
local new_slot=BLUE
fi
local NEW=${image_name}_${new_slot}
echo "Deploying '$NEW' in place of '$OLD'..."
docker run
--detach
--restart always
--log-driver journald
--name $NEW
--network web-gateway
$image_name || return 3
echo "Container started. Checking health..."
for i in {1..20}
do
sleep 1
if get-service-status $image_name $new_slot
then
echo "New '$NEW' service seems OK. Switching heads..."
sleep 2 # Ensure service is ready
set-active-slot $image_name $new_slot || return 4
echo "'$NEW' service is live!"
sleep 2 # Ensure all requests were processed
echo "Killing '$OLD'..."
docker rm -f $OLD
docker image prune -f
echo "Deployment successful!"
return 0
fi
echo "New '$NEW' service is not ready yet. Waiting ($i)..."
done
echo "New '$NEW' service did not raise, killing it. Failed to deploy T_T"
docker rm -f $NEW
return 5
}Використані функції:
ensure-reverse-proxy— Переконується, що реверс-проксі працює (корисно для першого деплою)get-active-slot service_name- Визначає який зараз слот активний для заданого сервісу (BLUEабоGREEN)get-service-status service_name deployment_slot— Чи визначає сервіс до обробки вхідних запитівset-active-slot service_name deployment_slot— Змінює конфіг nginx у контейнері реверс-проксі
По порядку:
ensure-reverse-proxy() {
is-container-up reverse-proxy && return 0
echo "Deploying reverse-proxy..."
docker network create web-gateway
docker run
--detach
--restart always
--log-driver journald
--name reverse-proxy
--network web-gateway
--publish 80:80
nginx:alpine || return 1
docker exec --interactive reverse-proxy sh -c "> /etc/nginx/conf.d/default.conf"
docker exec reverse-proxy nginx -s reload
}
is-container-up() {
local container=${1?"Usage: ${FUNCNAME[0]} container_name"}
[ -n "$(docker ps -f name=${container} -q)" ]
return $?
}
get-active-slot() {
local service=${1?"Usage: ${FUNCNAME[0]} service_name"}
if is-container-up ${service}_BLUE && is-container-up ${service}_GREEN; then
echo "Collision detected! Stopping ${service}_GREEN..."
docker rm -f ${service}_GREEN
return 0 # BLUE
fi
if is-container-up ${service}_BLUE && ! is-container-up ${service}_GREEN; then
return 0 # BLUE
fi
if ! is-container-up ${service}_BLUE; then
return 1 # GREEN
fi
}
get-service-status() {
local usage_msg="Usage: ${FUNCNAME[0]} service_name deployment_slot"
local service=${1?usage_msg}
local slot=${2?$usage_msg}
case $service in
# Add specific healthcheck paths for your services here
*) local health_check_port_path=":8080/" ;;
esac
local health_check_address="http://${service}_${slot}${health_check_port_path}"
echo "Requesting '$health_check_address' within the 'web-gateway' docker network:"
docker run --rm --network web-gateway alpine
wget --timeout=1 --quiet --server-response $health_check_address
return $?
}
set-active-slot() {
local usage_msg="Usage: ${FUNCNAME[0]} service_name deployment_slot"
local service=${1?$usage_msg}
local slot=${2?$usage_msg}
[ "$slot" == BLUE ] || [ "$slot" == GREEN ] || return 1
get-nginx-config $service $slot | docker exec --interactive reverse-proxy sh -c "cat > /etc/nginx/conf.d/$service.conf"
docker exec reverse-proxy nginx -t || return 2
docker exec reverse-proxy nginx -s reload
}Функція get-active-slot вимагає невеликих пояснень:
Чому вона повертає число, а чи не виводить рядок?
Все одно у викликаючій функції ми перевіряємо результат її роботи, а перевіряти exit code засобами bash набагато простіше, ніж рядок. До того ж, отримати з неї рядок дуже просто:
get-active-slot service && echo BLUE || echo GREEN.
А трьох умов точно вистачає, щоб розрізнити всі статки?
Навіть двох вистачить, останнє просто для повноти, щоб не писати else.
Залишилася невизначеною лише функція, що повертає конфіги nginx: get-nginx-config service_name deployment_slot. За аналогією з хелсчеком, тут можна встановити будь-який конфіг для будь-якого сервісу. З цікавого — лише cat <<- EOFщо дозволяє прибрати всі таби на початку. Щоправда, ціна гарного форматування – змішані таби з пробілами, що сьогодні вважається дуже поганим тоном. Але bash форсит таби, а конфізі nginx теж було б непогано мати нормальне форматування. Коротше, тут змішання табів з пробілами здається справді найкращим рішенням із найгірших. Однак, у Сніппет нижче Ви цього не побачите, так як хабр «робить добре», змінюючи всі таби на 4 пробіли і роблячи невалідним EOF. .
Щоб двічі не вставати, одразу розповім про
cat << 'EOF', Що ще зустрінеться далі. Якщо писати простоcat << EOF, то всередині heredoc проводиться інтерполяція рядка (розкриваються змінні ($foo), виклики команд ($(bar)) і т.д.), а якщо укласти ознаку кінця документа в одинарні лапки, то інтерполяція відключається і символ$виводиться як є. Те, що потрібно для вставки скрипта всередину іншого скрипта.
get-nginx-config() {
local usage_msg="Usage: ${FUNCNAME[0]} service_name deployment_slot"
local service=${1?$usage_msg}
local slot=${2?$usage_msg}
[ "$slot" == BLUE ] || [ "$slot" == GREEN ] || return 1
local container_name=${service}_${slot}
case $service in
# Add specific nginx configs for your services here
*) nginx-config-simple-service $container_name:8080 ;;
esac
}
nginx-config-simple-service() {
local usage_msg="Usage: ${FUNCNAME[0]} proxy_pass"
local proxy_pass=${1?$usage_msg}
cat << EOF
server {
listen 80;
location / {
proxy_pass http://$proxy_pass;
}
}
EOF
}Це є весь скрипт. І ось для скачки через wget або curl.
Виконання параметризованих скриптів на віддаленому сервері
Настав час стукати на цільовий сервер. Цього разу localhost цілком підійде:
$ ssh-copy-id localhost
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
himura@localhost's password:
Number of key(s) added: 1
Now try logging into the machine, with: "ssh 'localhost'"
and check to make sure that only the key(s) you wanted were added.Ми написали скрипт деплойменту, який перекачує заздалегідь зібраний образ на цільовий сервер та безшовно підміняє контейнер сервісу, але як його виконати на віддаленій машині? У скрипта є аргументи, тому що він універсальний і може деплоїти відразу кілька сервісів під один реверс-проксі (конфігами nginx можна розрулити по якому url який буде сервіс). Скрипт не можна зберігати на сервері, тому що в цьому випадку ми не зможемо його автоматично оновлювати (з метою багфіксів і додавання нових сервісів), та й взагалі, стейт = зло.
Рішення 1: Таки зберігати скрипт на сервері, але копіювати його кожного разу через scp. Потім підключитися по ssh та виконати скрипт з необхідними аргументами.
Мінуси:
- Дві дії замість однієї
- Місця, куди ви копіюєте, може не бути, або не бути до нього доступу, або скрипт може виконуватися в момент заміни.
- Бажано прибрати за собою (видалити скрипт).
- Вже три дії.
Рішення 2:
- У скрипті тримати лише визначення функцій і взагалі нічого запускати
- За допомогою
sedдописувати в кінець виклик функції - Надсилати все це прямо у shh через pipe (
|)
Плюси:
- Truely stateless
- No boilerplate entities
- Відчуття прохолоди
Ось давайте тільки без Ansible. Так, все вже вигадано. Так, велосипед. Дивіться, який простий, елегантний та мінімалістичний велосипед:
$ cat << 'EOF' > deploy.sh#!/bin/bash
usage_msg="Usage: $0 ssh_address local_image_tag"
ssh_address=${1?$usage_msg}
image_name=${2?$usage_msg}
echo "Connecting to '$ssh_address' via ssh to seamlessly deploy '$image_name'..."
( sed "$a deploy $image_name" | ssh -T $ssh_address ) << 'END_OF_SCRIPT'
deploy() {
echo "Yay! The '${FUNCNAME[0]}' function is executing on '$(hostname)' with argument '$1'"
}
END_OF_SCRIPTEOF
$ chmod +x deploy.sh
$ ./deploy.sh localhost magic-porridge-pot
Connecting to localhost...
Yay! The 'deploy' function is executing on 'hut' with argument 'magic-porridge-pot'Однак, ми не можемо бути впевнені, що на віддаленому хості є адекватний bash, так що додамо на початок невелику перевірку (це замість ):
if [ "$SHELL" != "/bin/bash" ]
then
echo "The '$SHELL' shell is not supported by 'deploy.sh'. Set a '/bin/bash' shell for '$USER@$HOSTNAME'."
exit 1
fiА тепер все по-справжньому:
$ docker exec reverse-proxy rm /etc/nginx/conf.d/default.conf
$ wget -qO deploy.sh https://git.io/JUURc
$ chmod +x deploy.sh
$ ./deploy.sh localhost uptimer
Sending gzipped image 'uptimer' to 'localhost' via ssh...
Loaded image: uptimer:latest
Connecting to 'localhost' via ssh to seamlessly deploy 'uptimer'...
Deploying 'uptimer_GREEN' in place of 'uptimer_BLUE'...
06f5bc70e9c4f930e7b1f826ae2ca2f536023cc01e82c2b97b2c84d68048b18a
Container started. Checking health...
Requesting 'http://uptimer_GREEN:8080/' within the 'web-gateway' docker network:
HTTP/1.0 503 Service Unavailable
wget: server returned error: HTTP/1.0 503 Service Unavailable
New 'uptimer_GREEN' service is not ready yet. Waiting (1)...
Requesting 'http://uptimer_GREEN:8080/' within the 'web-gateway' docker network:
HTTP/1.0 503 Service Unavailable
wget: server returned error: HTTP/1.0 503 Service Unavailable
New 'uptimer_GREEN' service is not ready yet. Waiting (2)...
Requesting 'http://uptimer_GREEN:8080/' within the 'web-gateway' docker network:
HTTP/1.0 200 OK
Server: BaseHTTP/0.6 Python/3.8.3
Date: Sat, 22 Aug 2020 20:15:50 GMT
Content-Type: text/html
New 'uptimer_GREEN' service seems OK. Switching heads...
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
2020/08/22 20:15:54 [notice] 97#97: signal process started
The 'uptimer_GREEN' service is live!
Killing 'uptimer_BLUE'...
uptimer_BLUE
Total reclaimed space: 0B
Deployment successful!Тепер можна відкрити у браузері, запустити деплоймент ще раз і переконатися, що він проходить безшовно шляхом оновлення сторінки КД під час викладки.
Не забуваємо забиратися після роботи :3
$ docker rm -f uptimer_GREEN reverse-proxy
uptimer_GREEN
reverse-proxy
$ docker network rm web-gateway
web-gateway
$ cd ..
$ rm -r blue-green-deploymentДжерело: habr.com