Secret / env variable not getting substituted for dev environments

Remote Development Environments
1

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:

"helm upgrade --install chart ./helm --set db_url='${DATABASE_URL}'"

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?

thanks!

2

Welcome to our community @benjoldersma !

Not sure I fully understand your scenario. Let me see if I understand what you’re doing:

  1. You have a secret in Okteto called DATABASE_URL
  2. When you execute your GitHub action, the secret is correctly propagated to your command.
  3. When you run okteto up to the environment you deployed on Okteto, the environment variable is unavailable.

Is that correct?

If so, could you share your okteto.yaml file? (remove all that it’s confidential )

3

Thanks Ramiro!

Here you go:

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

The helm chart is super simple, basically

values.yaml:

db_url: 'none'

templates/k8s.yaml:

    spec:
      containers:
      - name: fuji-service
        env:
          - name: DATABASE_URL
            value: {{ .Values.db_url}}

I think, writing this, I may have just solved it :slight_smile: 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!

best,

– ben

4

Out of curiosity, why do you need a different database for your preview environments than for your development environments?

5

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 :slight_smile:

1 Like
6

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.

7

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!

8

Perfect!! Along with this readme to show how to use it in the action:

        name: pr-${{ github.event.number }}-cindylopez
        scope: global
-
+        file: "okteto-with-volumes.yaml"
+        variables: "API_LOAD_DATA=false,DB_SNAPSHOT_NAME=dbdata-snapshot,DB_SNAPSHOT_NAMESPACE=movies-test"

I’ll take a look tomorrow. Thanks Ramiro!

1 Like