У меня есть постоянная ошибка, в этом случае при попытке запустить модульные тесты Django внутри контейнера.
test_1 | Traceback (most recent call last):
test_1 | File "/usr/local/bin/django-admin", line 11, in <module>
test_1 | sys.exit(execute_from_command_line())
test_1 | File "/usr/local/lib/python3.6/site-packages/django/core/management/__init__.py", line 371, in execute_from_command_line
test_1 | utility.execute()
test_1 | File "/usr/local/lib/python3.6/site-packages/django/core/management/__init__.py", line 317, in execute
test_1 | settings.INSTALLED_APPS
test_1 | File "/usr/local/lib/python3.6/site-packages/django/conf/__init__.py", line 56, in __getattr__
test_1 | self._setup(name)
test_1 | File "/usr/local/lib/python3.6/site-packages/django/conf/__init__.py", line 43, in _setup
test_1 | self._wrapped = Settings(settings_module)
test_1 | File "/usr/local/lib/python3.6/site-packages/django/conf/__init__.py", line 106, in __init__
test_1 | mod = importlib.import_module(self.SETTINGS_MODULE)
test_1 | File "/usr/local/lib/python3.6/importlib/__init__.py", line 126, in import_module
test_1 | return _bootstrap._gcd_import(name[level:], package, level)
test_1 | File "<frozen importlib._bootstrap>", line 994, in _gcd_import
test_1 | File "<frozen importlib._bootstrap>", line 971, in _find_and_load
test_1 | File "<frozen importlib._bootstrap>", line 955, in _find_and_load_unlocked
test_1 | File "<frozen importlib._bootstrap>", line 665, in _load_unlocked
test_1 | File "<frozen importlib._bootstrap_external>", line 678, in exec_module
test_1 | File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed
test_1 | File "/advocate/advocate/settings/test-microservice.py", line 1, in <module>
test_1 | from .base import *
test_1 | File "/advocate/advocate/settings/base.py", line 378, in <module>
test_1 | 'client_x509_cert_url': 'https://www.googleapis.com/robot/v1/metadata/x509/{}'.format(get_env_setting('GS_CLIENT_EMAIL')).replace('@', '%40'),
test_1 | File "/usr/local/lib/python3.6/site-packages/google/oauth2/service_account.py", line 193, in from_service_account_info
test_1 | info, require=['client_email', 'token_uri'])
test_1 | File "/usr/local/lib/python3.6/site-packages/google/auth/_service_account_info.py", line 54, in from_dict
test_1 | signer = crypt.RSASigner.from_service_account_info(data)
test_1 | File "/usr/local/lib/python3.6/site-packages/google/auth/crypt/base.py", line 115, in from_service_account_info
test_1 | info.get(_JSON_FILE_PRIVATE_KEY_ID))
test_1 | File "/usr/local/lib/python3.6/site-packages/google/auth/crypt/_python_rsa.py", line 174, in from_string
test_1 | raise ValueError('No key could be detected.')
test_1 | ValueError: No key could be detected.
Насколько я понимаю, это происходит, когда пакет google пытается аутентифицироваться, но нене получить действительный ключ RSA.В других, то есть не докерских, контекстах, которые я видел и исправил эту ошибку, изменив представление символов новой строки закрытого ключа RSA, в зависимости от того, как он читался из оболочки / файла и т. Д. В некоторых случаях это требовалось \n, или \\n, или буквальный перевод строки.
В текущем случае у меня есть Dockerfile и я использую docker-compose для запуска контейнера, выполняющего юнит-тесты.Я уверен, что docker-compose предоставляет секреты из файлов.(Да, это то, что я хочу в этом случае, пожалуйста, не вызывайте Swarm) Если, например, я закомментирую строку в файле .env с секретным ключом, GS_PRIVATE_KEY=/run/secrets/GS_PRIVATE_KEY, Django вылетает с django.core.exceptions.ImproperlyConfigured: Set the GS_PRIVATE_KEY env variable,так что я знаю, что он получает некоторый вероятный набор значений.Все остальные секреты работают отлично.Так как я полагаю из предыдущих случаев, что это вызвано кодировкой символов, я пробовал каждую попарную комбинацию (кавычки, перевод строки) в
[", ', `, <no quotes>], [\n, \\n, <literal return>, %0A]
Все 16 версий файла закрытого ключа терпят неудачу.Я не уверен, что попробовать дальше, или как получить больше информации из моих попыток.
(отредактировано) ВИД РАБОТЫ: решение, которое «сработало», заключалось в создании другого сценария, set_key.sh с
export GS_PRIVATE_KEY=$(cat /run/secrets/GS_PRIVATE_KEY)
и префиксе каждой точки входа с ./set_key.sh &&
Это работает, когда ключ находится в \n формате
Хотя я не считаю это ответом на вопрос, так как это наверняка кажется излишним.Все секреты уже присваиваются соответствующим переменным в файле .env.Зачем мне перезаписывать это содержимое /run/secrets/GS_PRIVATE_KEY снова ?