You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I had searched in the issues and found no similar feature requirement.
Use case
As a user, I would like to upgrade the devlake smoothly without losing my data.
Description
Why do we need it?
The encKey or ENCODE_KEY was introduced a long time ago to encrypt sensitive information (e.g. access token, password, etc) stored in the database.
What went wrong?
We decided to generate the encryption key and save it to the .env file automatically on the first boot if it was omitted in order to make the installation process smoother.
However, it has been proven problematic along the way:
bad naming
the devlake container must be deployed as a stateful set, since we have to write the key back to the .env file
users often do not aware of the key and run into encKey after upgrading if they chose to deploy a completely new instance with the existing database
What can we do about it?
Users should be properly informed about the encryption key, and how should they do about it.
Plan of attack
Unify encKeyENCODE_KEY to encryptionSecret / ENCRYPTION_SECRET both codebase and documentation
Make .env file Readonly and Optional in codebase: devlake backend could still read setting from dotenv file IFF it exists
Remove the auto-generate logic from our code base, devlake should fail if no ENCRYPTION_SECRET is provided
v0.18 Installation Guide to ask users to generate the ENCRYPTION_SECRET manually with some example command, and ask them to store it properly if they want to deploy a brand new instance using the existing database.
Please NOTE that we are deprecating the reading/wrting from devlake to the .env, you may still use it as env_file in the docker-compose.yml, it is not related to the topic.
Search before asking
Use case
As a user, I would like to upgrade the
devlakesmoothly without losing my data.Description
Why do we need it?
The
encKeyorENCODE_KEYwas introduced a long time ago to encrypt sensitive information (e.g. access token, password, etc) stored in the database.What went wrong?
We decided to generate the encryption key and save it to the
.envfile automatically on the first boot if it was omitted in order to make the installation process smoother.However, it has been proven problematic along the way:
devlakecontainer must be deployed as astatefulset, since we have to write the key back to the.envfileencKeyafter upgrading if they chose to deploy a completely new instance with the existing databaseWhat can we do about it?
Users should be properly informed about the encryption key, and how should they do about it.
Plan of attack
encKeyENCODE_KEYtoencryptionSecret/ENCRYPTION_SECRETboth codebase and documentation.envfile Readonly and Optional in codebase:devlake backendcould still read setting from dotenv file IFF it existsdevlakeshould fail if noENCRYPTION_SECRETis providedENCRYPTION_SECRETmanually with some example command, and ask them to store it properly if they want to deploy a brand new instance using the existing database.ENCODE_KEYand set it up on the new versionNote
Please NOTE that we are deprecating the reading/wrting from
devlaketo the.env, you may still use it asenv_filein thedocker-compose.yml, it is not related to the topic.Related issues
Are you willing to submit a PR?
Code of Conduct