Thomas Storm

Добавить строчку rewrite ^/jira(.*)$ $1 last;

server {
    listen some_ip:443;
    server_name jira.example.com;

    ssl on;
    ssl_certificate /etc/nginx/ssl/example-com-new.crt;
    ssl_certificate_key /etc/nginx/ssl/example-com-new.key;
    ssl_prefer_server_ciphers On;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
   

    client_max_body_size 32m;

rewrite ^/jira(.*)$ $1 last;

    location / {
      proxy_set_header        Host $server_name;
      proxy_set_header        X-Real-IP $remote_addr;
      proxy_set_header        X-Forwarded-For $remote_addr;
      proxy_redirect          http:// https://;
      proxy_pass              http://Jira_upstream/;
    }

}

ИП нужно, если платежи регулярные и хочется все с налогами правильно сделать

иначе же - можно не заморачиваться

Можно решить через ${VAR#*@} и ${VAR%@*}, либо ${VAR##*@} и ${VAR%%@*}
первый попавшийся символ @, либо по последний.

#!/bin/bash

AAA="First_word@First_line\nSecond_word@Second_line\nThird_word@Third_line"

echo -e "${AAA}" | while read line; do
    if [ "$1" == "${line%@*}" ]; then
        echo "Second part of the line: ${line#*@}"
    fi
done

Предположу, что вы кот и ваш хозяин купил лазерную указку)

1) Какие инженерные задачи вы решали с помощью питона? Почему не баш/пауэршелл?

Как и любой другой язык общего назначения, практически любую задачу автоматизации можно реализовать на python. Просто наблюдайте за собой и смотрите, что бы вам хотелось автоматизировать в работе или бытовой жизни. Я, например, парсю серверные логи, вычленяю из них ошибки и визуализирую себе это поверх http.

2) Есть ли какие-то ресурсы, где можно посмотреть на реализацию питоновских скриптов в администрировании? гитхаб?

Собственно, Ansible. К тому же он сам написан на python, по этому любые новые плагины или какие-то продвинутые автоматизации вы должны будете писать на python.

Тестировщиком легко сможет стать. Примеров масса, даже среди знакомых.
Вот программистом сложнее, у меня самого юридическое образование. Было очень сложно переквалифицироваться и заняло годы. В 30 лет такой процесс начать сложнее, тут нужен просто феерический энтузиазм и интерес к профессии.

В начале цикла делаете проверку
if [[ "$i" == "superelement" ]]; then
tralalal
continue
fi

Ключевое слово - continue

https://docs.mirantis.com/openstack/fuel/fuel-6.1/...

www.sql.ru/forum/1160776/arhitektura-postgresql

Изучите систему управления . получите понимание о бизнес-процессах . Это минимум .
Хорошо помогут знание психологии и HR компетенции.
Будут вопросы -пишите .

как-то так:

sqlplus -s system/*** @show_users.sql | sed -n '1,/---/d;/\s/q;p'

Нет никаких годных материалов. Точнее они годные только для опытных DevOps. Потому что это культура подхода, а не инструментарий.
Переход на DevOps делается в три этапа:
1) Сначала полностью все автоматизируется. По поводу доставки кода вопросы врядли возникнут - Jenkins и Maven известны даже детям. Ну не обязательно они. У каждого языка свои инструменты. gradle, grunt, waf... Но автоматиризровать надо все, включая деплой SQL (LiquidBase, dbMaintain, sqitch и т.д.). Эта часть освещена очень хорошо в интернетах.
2) Затем убираются все боттл-нэки в работе админов и программистов. Например внедряется Green/Blue-деплоймент. В точках деплоя собственного ПО средства провиженинга (puppet/ansible/chef) заменяются на средства деплоймента (uDeploy например). Устанавливается мониторинг и логирование. На все это тоже есть свои инструменты (Sensu например).
3) Начинается работа с людьми - вовлечение программистов в ответственность за результат на стороне Ops и вовлечение сисадминов(operations) в результат на стороне Dev (подгон под FHS и все такое). Ключевой момент в том, что людям придется понять, что их ответственность приходит эхом оттуда, где они своими руками не трогали (для этого даже автоматически создают новые энвайронменты всякими докерами и вагрантами). Закоммитил кривой код в IDE, не учел зависимость в пропертях, поправил конфиги не для всех энвайронментов - будешь отвечать и за статический анализ кода и за проваленные интеграционные тесты и за неудачный деплоймент. В обратную сторону тоже самое. Тогда люди начнут действовать по стандартам и настанет искомый результат.

Ну и само собой надо найти сильного релиз-инженера. Потому что DevOps - это не "построил и ушел". Кто-то должен все время смотреть за новыми организационными проблемами и чтобы транк не попал на UAT, например, а на SIT ушел тот же тэгированный код, которому на DEV провели smoke-тесты, а не обновленный парой вредных коммитов, набежавших за время смоука.

Сначала скажите, как звучит конечная задача и что из этого уже есть и чего нет. Может чего детальнее посоветую.