Trouble migrating to EnvKey 2

[drcongo]

Hello. We have around 60 apps, running on staging and production servers, so I've been trying to be methodical and write up my process for switching a running server over from EnvKey 1 to EnvKey 2 but I can't get even the first one working. Importing the app environments into v2 worked fine (when I used JSON), but it's getting the remote servers running on v2 where it all falls down. This is what I've written up so far...

1. Generate a server key for the correct environment
2. ssh into the server
3. nano .env, comment out the old key, and paste the new key in as the top line
4. delete envkey-source v1: rm $(which envkey-source)
5. Install envkey-source v2:

VERSION=$(curl https://envkey-releases.s3.amazonaws.com/latest/envkeysource-version.txt) && curl -s https://envkey-releases.s3.amazonaws.com/envkeysource/release_artifacts/$VERSION/install.sh | bash

6. Test the installation / key with es -- echo $EMAIL_HOST_URL

The output from 6 and any es / envkey-source command I run though is ENVKEY invalid. Have I messed a step? I've double checked the generated key, I've tried adding it also to the $HOME/.envkey/apps/{etc}.env path, I've tried running the commands with the --env-file flag, all produce the same result.

edit: The output from envkey-source --version is 2.1.1

[danenania]

Hi @drcongo, a few questions:

1 - Do you have an envkey.json file in your app directory? You can add one by running the envkey init CLI command locally, then committing the file.

2 - To narrow down the issue, does it work if you run it like this:

ENVKEY=... es -- echo $EMAIL_HOST_URL

Replace ENVKEY above with the v2 ENVKEY you generated.

3 - If 2 doesn't work above on the server, does it work for you locally?

[drcongo]

Hi @danenania

1. I have a .envkey file which was generated by the desktop app, I've put that on the server too but with the same result.
2. Running that on the remote produces a blank output. I'd guess that means it's accepting the envkey but not getting the value somehow?
3. Running that locally outputs echo 'error: ENVKEY invalid'; false

[danenania]

Oops, for the echo to work, you'll need to wrap single quotes around the variable, otherwise it gets evaluated immediately rather than after envkey-source loads:

ENVKEY=... es -- echo '$EMAIL_HOST_URL'

You could also try just outputting all your vars as json:

ENVKEY=... es --json

But the fact that you got an empty result rather than an error makes it sound like it did load correctly. Assuming that's the case, it sounds like perhaps when you don't precede with the ENVKEY=... that another invalid ENVKEY might be taking precedence, perhaps because an ENVKEY environment variable is already set.

If you run es with the --verbose flag, that should make it clear what ENVKEY is being used. You should send that output to [email protected] rather than posting here since it could include the first half of your ENVKEY.

es --verbose --json

[drcongo]

Thanks @danenania, having seen your email come in last night I think I'll wait for that seamless transition!

[SeriousM]

Hi @danenania,

any updates on the seamless transition?

Thanks

[dbsanfte]

Thanks @danenania that sounds pretty good.

What is the behavior of older versions of envkey-source and envkey node/python/c# SDKs when attempting to load vars against an app migrated from v1 to v2? This is the principal problem we have at the moment, namely that we have containers deployed that use these libs and require a recompile to upgrade. If it would all Just Keep Working that would be a lifesaver.

[danenania]

@dbsanfte After an app is moved from v1 to v2, SDKs that are still on a 1.x.x version will continue to load ENVKEYs from v1, but won't pick up any updates that are made in v2. Once an SDK is updated to 2.3.0 or higher, it will then load from v2 using the same ENVKEY (including any changes made in v2).

In your case I think the ideal workflow would be:
1 - Upgrade remaining apps from v1 to v2 using the automated upgrade.
2 - Temporarily avoid making any changes to those apps.
3 - Bump up SDK versions to >= 2.30--everything will keep working in the meantime even if you have a mix of 1.x.x and >= 2.3.0 SDK versions.
4 - Now you can make changes in v2--you're fully upgraded.

Does that sounds like it will work for you? I don't think there's any way around the need to bump up the SDK versions as 1.x.x clients can't decrypt data coming from v2.

[drcongo]

A thing we've found that may help others: Our apps run under supervisord and wouldn't start with the v1 envkey still in place, but upgrading the key to a v2 key fixed it. Everything else seemed to work fine with the v1 key, like manual commands and testing in iPython etc. but for some reason starting the app from supervisor failed.

[danenania]

@drcongo Interesting, were you getting an error message when using supervisord?

[drcongo]

No, it was just falling to get any of the variables so the app would fail to start. We're going to need to upgrade the keys eventually across all the servers anyway, so it's not really a problem for us and it was almost certainly user error.