Пост Засмутили ви мене того тижня — жодного коментаря 😢 Шо, ніхто не відстежує час, витрачений на проєкти? Ну то таке…

Засмутили ви мене того тижня — жодного коментаря 😢 Шо, ніхто не відстежує час, витрачений на проєкти? Ну то таке… Сьогодні хотів знову зачепити тему роботи з «секретами» при розробці проєктів, а саме: з паролями, API-ключами, токенами тощо. Мені особисто дуже муляє око, коли вони у відкритому вигляді на диску лежать, навіть якщо цей файл не потрапляє в ґіт. Ну, власне, тому я їх відкрито вже давно й не тримаю. Колись уже розповідав, як використовую 1Password для підписування комітів та роботи з Ansible 💻. А сьогодні хотів трохи написати про .env-файли. Проблема з ними якраз і полягає в тому, що вони в ґіті не зберігаються. Тобто щоразу, як зробив чистий клон проєкту, треба цей файл руками створювати. Звісно, можна покласти .env.example, в якому принаймні назви всіх змінних будуть, але спробуй ще згадай, де і як ти ті ключі та токени отримував. У мене їх десятки, всі з різними правами й скоупами, і я швидко починав у цьому губитися. Тому нині мої .env на вигляд зазвичай приблизно отакі: GITHUB_TOKEN="op://Work/repo-name/wrxqfrltnqlzgako6zx6fjak6m/GITHUB_TOKEN" TF_VAR_github_app_private_key="op://Work/repo-name/private key" TF_VAR_crowdin_token="op://Work/repo-name/CROWDIN_PERSONAL_TOKEN/value" TF_VAR_discord_webhook="op://Work/repo-name/DISCORD_WEBHOOK_URL/value" TF_VAR_rclone_config="op://Work/repo-name/RCLONE_CONFIG/value" Вочевидь, тут нема жодних секретів, які не можна було б зберігати в системі контролю версій, бо значення змінних — це просто посилання на конкретні записи 1Password. До того ж не треба взагалі нічого міняти: зробив клон — і все одразу працює. Єдиний мінус полягає в тому, що тепер замість умовного terraform apply доводиться писати op run --env-file=".env" -- terraform apply Я, звісно, махав це щоразу руками друкувати, тому використовую just, про який теж неодноразово вже згадував. А нещодавно дізнався про ще одну нову альтернативну фічу 1Password (наразі бета). Тепер вони дозволяють створювати різні оточення зі своїми наборами секретів прямо в їхній програмі. І потім такі оточення можна монтувати за певним шляхом як .env-файл. Але! Файлу насправді нема 🙂 Замість того, щоб записувати ці всі секрети відкрито на диск, вони просто створюють іменований жолоб (pipe по-вашому): щойно хтось намагається прочитати звідти дані, 1Password просить вас авторизувати цей запит і передає значення прямо в програму! Ніби нічого складного, але доволі креативний розвʼязок до проблеми. Переваги підходу в тому, що ви запускаєте всі свої тулзи як зазвичай — без жодних op run. А головний мінус для мене: наразі все ж не дуже зручно цим керувати. До того ж після клонування треба заходити й монтувати це оточення в потрібну теку. Тож для себе я вирішив лишитися на попередньому варіанті. Взагалі подобається, що 1Password не стоїть на місці й постійно розвивається. Але не подобається, що вони й так не дешеві, а скоро ще й піднімають вартість передплати 🥲