I have a DATABASE_URL that I’m configuring for my preview environments, and using a github action to run integration tests against. That works great, as a secret from the okteto UI. (and deploying it like:
but… when I do okteto up to dev, I end up with this in my env:
# env | grep DA
DATABASE_URL=${DATABASE_URL}
Which is not valid. For dev, I’m supplying the env value from the .env file. But, that value doesn’t take precedence what gets supplied to the container from okteto. I can unset the environment variable each time, but that’s a bit of a pain.
Any ideas? Is there a way to conditionally execute a deployment if we’re in preview vs dev?
name: fuji-service
# The build section defines how to build the images of your development environment
# More info: https://www.okteto.com/docs/reference/manifest/#build
build:
# You can use the following env vars to refer to this image in your deploy commands:
# - OKTETO_BUILD_HELLO_ROCKET_REGISTRY: image registry
# - OKTETO_BUILD_HELLO_ROCKET_REPOSITORY: image repo
# - OKTETO_BUILD_HELLO_ROCKET_IMAGE: image name
# - OKTETO_BUILD_HELLO_ROCKET_SHA: image tag sha256
fuji-service:
context: .
dockerfile: Dockerfile
# The deploy section defines how to deploy your development environment
# More info: https://www.okteto.com/docs/reference/manifest/#deploy
deploy:
#- kubectl apply -f k8s.yaml
- helm upgrade --install chart ./helm --set db_url="${DATABASE_URL}"
# The dependencies section defines other git repositories to be deployed as part of your development environment
# More info: https://www.okteto.com/docs/reference/manifest/#dependencies
# dependencies:
# - https://github.com/okteto/sample
# The dev section defines how to activate a development container
# More info: https://www.okteto.com/docs/reference/manifest/#dev
dev:
fuji-service:
selector:
app: fuji-service
image: okteto/rust:1.64
command: bash
workdir: /usr/src/app
sync:
- .:/usr/src/app
volumes:
- /usr/local/cargo/registry
- /home/root/app/target
persistentVolume:
enabled: true
storageClass: okteto-standard
size: 3Gi
I think, writing this, I may have just solved it I think I can just use two different env vars and handle the override logic. I’m new to rust, but it looks like their implementation of dotenv just chooses to overlay process env variables over the values in the .env files.
but, if there’s a preferred way to fork configs between dev and preview that would certainly be interesting to know!
Yeah, that’s a great question. I’m using cockroachdb. And with the limits that the version of okteto saas I’m currently using, I don’t have enough resources to run a single-node instance in the env. so for now, I’m using a shared db for previews. Eventually, when we get moved over to self-hosted / more resources, I’d like to spin up a local cocroachdb for preview environments.
but… dev environments I’m still leaning towards using cockroach’s serverless version for, less hassle / more portability. i dunno. I’m def. still at the learning stage, and open to suggestions / best practices
Another use case where being able to distinguish between dev/preview/prod can be useful conveying that to users in UIs. At past companies we’ve put banners / motds up, perhaps with different colored backgrounds, to help avoid committing a change in a wrong environment.
Thanks for the explanation, it makes a lot of sense!
This pattern has worked for me in the past:
Make the development version your ‘default version’ in your manifest (this is because you will have more dev envs than preview envs or prod). That way, okteto up just works.
On preview environments, use the variables to pass the required values. You could set a preview=true value there, and then have your app manifests interpret this to use the shared DB instead of spinning up a new one.
It’s not well documented (we will update this soon), but the ‘deploy’ section of the okteto.yaml can take multiline scripts, in case you want a command with branches. This is an example of a manifest that uses the existence of a variable to run on a variation of helm install vs a second variation. You could use something like that to decide when to deploy cockroach and when to use the shared version.
PS This topic would make for an exciting blog post or tutorial. I’ll follow up with our team to add it to our content queue. Looking forward to hearing your thoughts on this!
Starting on 1.18, okteto will set the value of OKTETO_IS_PREVIEW_ENVIRONMENT to true when the environment is a preview environment. You can check the value of this variable on the deploy section of your okteto.yaml to perform different actions when you are deploying a preview environment.