alex
December 18, 2020, 10:55am
1
Flyctl version = 0.0.156
I am setting the flyctl secrets
via
flyctl secrets set TEST_SECRET=zipadeedoodahh
then i dumped all the environment variables via golang in the (attached) repo link.
Problem is, the TEST_SECRET env var is not visible from the application (runtime).
Runtime logs:
https://pastebin.com/0BHmyh8A
Code is here:
https://github.com/WinWisely268/fly-grpcweb
Relevant part of the code:
https://github.com/WinWisely268/fly-grpcweb/blob/5913565dfb9a5e069bbd38d58f324e0982e7b6a4/main.go#L59
for _, pair := range os.Environ() {
log.Print("====================")
log.Print(pair)
log.Print("====================")
}
testSecret := os.Getenv("TEST_SECRET")
if testSecret == "" {
log.Fatalf("unable to load TEST_SECRET: it's empty")
}
Also when i do:
`flyctl secrets list`
i cannot see anything, but when i do
❯ flyctl releases list
VERSION STABLE TYPE STATUS DESCRIPTION USER DATE
v6 true rollback succeeded Reverting to version 4 29m34s ago
v5 false release failed Deploy image some_mail 30m11s ago
v4 true release succeeded Secrets updated some_mail 37m56s ago
v3 true release succeeded Deploy image some_mail 2020-12-14T08:23:20Z
v2 true rollback succeeded Reverting to version 0 2020-12-14T08:05:01Z
v1 false release failed Deploy image some_mail 2020-12-14T08:02:21Z
v0 true release succeeded Deploy image some_mail 2020-12-13T18:21:28Z
Is there anything i might’ve done wrong or can anyone give me some pointer to the right direction?
Appreciate any help. Thanks
jerome
December 18, 2020, 2:18pm
2
Looking at your app (at least, the one I think it is), there might be a bug on our end. I don’t see any releases that included your secret.
There is some awkwardness sometimes with rollbacks and secrets. We need to work on this (unfortunately) bad experience.
We’ll look into more details and figure out what happened.
Meanwhile, can you give it another shot? And please confirm the name of the app where this is happening.
alex
December 18, 2020, 4:55pm
3
Hi, thanks for the kind response!
Unfortunately i nuked the whole app then start it from scratch again (using the same name), still no dice.
Name of the app is late-moon-415
Here are the steps i took (in picture):
on failed deployment the flyctl secrets list
doesn’t show anything though, is that normal?
It is fine, i’m just trying to evaluate fly before i use it for real, is there any other advice you can give me in order for me to do something about it or should i just wait for a fix?
Appreciate it, thanks.
michael
December 18, 2020, 5:12pm
4
@alex we’ll have a fix out shortly
michael
December 18, 2020, 5:35pm
5
@Alex this should be fixed now, sorry about that!
1 Like
I’m having similar issue reading variable from secrets in a Deno App.
Environment variables from fly.toml
just read fine. But environment variables from secrets, come out undefined
.
Even after updating variable values, they were undefined
.
But interestingly, after adding a new variable to secrets, they were all read, even those which were previously undefined
. There is some sort of bug here.
1 Like
@amithm7 Thanks for pointing this out. Just to confirm, was this in the VMs that were running, or restricted to the release phase VM that runs inside each deployment?
Live VMs that are running. Not the release phase VM.
Release list:
v51 true release succeeded Secrets updated email 23m33s ago
v50 true release succeeded Deploy image email 26m18s ago
... debugging image deploys ...
v41 true release succeeded Deploy image email 15h17m ago
v40 true release succeeded Secrets updated email 15h20m ago
v39 true release succeeded Deploy image email 15h22m ago
v38 true release succeeded Secrets updated email 15h26m ago
v37 true release succeeded Secrets updated email 17h22m ago
v36 true release succeeded Deploy image email 17h23m ago
v35 true release succeeded Secrets updated email 2021-10-25T12:36:34Z
Here, v35 is probably first upload of secrets. v37, 38 and 40 is me trying to update the variables. They were read as undefined
.
v51 is when I added a dummy variable. After that, all secrets could be read by the app.
Thanks, this is super helpful. We’ll figure out what’s happening.
1 Like
Is this possibly related to this?
After a new deploy I noticed some logs about connection errors to redis, and it was trying to connect to 127.0.0.1 so figured it was missing the ENV, tried setting it, but the CLI would state no changes were made meaning the app has this ENV variable and its the same value, but then I triggered a redeploy and everything was fine after that, no more connection errors.
There is two reason I believe this was a bug with missing ENVs:
default fallback address being used “127.0.0.1”
I was not able …
1 Like