Наверняка вы замечали, что в Python есть удобная функция для получения переменной окружения
os.getenv(NAME)
И её "сестра" для создания или изменения переменных окружения
os.putenv(NAME, VALUE)
Но почему-то putenv() не работает как должно. Энвайромент не обновляется!
os.putenv('MYVAR', '1')
print(os.getenv('MYVAR'))
... и ничего 😴
Почему так?
На самом деле энвайромент обновляется, но это значение не добавляется в словарь os.environ.
Откройте исходник функции os.getenv(). Это просто шорткат для os.environ.get()
В то время как putenv() это built-in С-функция.
Словарь os.environ (или точней класс из MutableMapping) создаётся из энвайромента в момент инициализации. Функция putenv() самостоятельно его не изменяет.
В тоже время, когда вы создаёте или изменяете ключ в os.environ, автоматически вызывается putenv() в методе __setitem__().
То есть, технически putenv() всё делает верно, но в os.environ это не отражается. Можно проверить так:
>>> os.putenv('MYVAR', '123')
>>> os.system('python -c "import os;print(os.getenv(\'MYVAR\'))"')
123
Я объявил переменную в текущем процессе и вызвал дочерний процесс, который её унаследовал и получил в составе os.environ.
Аналогично при удалении переменной вызывается еще одна built-in функция unsetenv(), удаляющая переменную из системы.
Итого
▫️ Удобней всего явно обновлять переменные через os.environ
▫️ Есть способ неявно создать/удалить переменную через putenv/unsetenv, что не повлияет на os.environ но изменит энвайромент и передаст изменения сабпроцессам. Но так лучше не делать!
▫️os.environ это просто обертка для built-in функций putenv() и unsetenv().
#basic
📋 Disaster Recovery Plan: Как правильно заваривать чай, когда горит серверная.
• В жизни любого проекта наступает катастрофа. Мы не можем заранее знать, что именно это будет - короткое замыкание в серверной, инженер, дропнувший центральную БД или нашествие бобров. Тем не менее, оно обязательно случится, причем по предельно идиотской причине.
• Кстати, насчет бобров - это не шутка. В Канаде они перегрызли кабель и оставили целый район без оптоволоконной связи. А в топе источника проблем для крупной телекоммуникационной компании Level 3 Communications вообще были белки.
• Короче, рано или поздно, кто-то обязательно что-то сломает, уронит, или зальет неверный конфиг в самый неподходящий момент. И вот тут появляется то, что отличает компании, которые успешно переживают фатальную аварию от тех, кто бегает кругами и пытается восстановить рассыпавшуюся инфраструктуру - DRP. Вот о том, как правильно написать Disaster Recovery Plan мы сегодня и поговорим:
➡️Читать статью [10 min].
#DevOps
🗺 DevOps Roadmap
• Держите крутой и актуальный roadmap для DevOps, который включает в себя необходимые ссылки на обучающие материалы для каждого шага на этом пути.
➡️https://github.com/milanm/DevOps-Roadmap
- GIT;
- Learn one programming language;
- Learn Linux & Scripting;
- Learn Networking & Security;
- Learn Server Management;
- Learn Containers;
- Learn Container Orchestration;
- Learn Infrastructure as a code;
- Learn CI/CD;
- Learn Monitoring & Observability;
- Learn one Cloud provider;
- Learn Software Engineering Practices;
- Additional resources;
- Tools;
- Books.
#DevOps