I have this manifest.yml:
applications:
- name: xx
buildpack: java-bp480-v2
instances: 2
memory: 2G
path: webapp/build/libs/trid.war
services:
- xxservice
- xxservice
- xxcktbrkrcnfgsvc
- xxappdynamics
- autoscaler-xx
env:
spring_profiles_active: cloud
swagger_active: false
JAVA_OPTS: -Dspring.profiles.active=cloud -Xmx1G -Xms1G -XX:NewRatio=1 -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps
What will env do?.
Will that create three environment variables or it will append JAVA_OPTS to the start command if the spring profile active is cloud?.
What will env do?.
The env block will instruct the cf cli to create environment variables on your behalf. Entries take the form variable_name: variable_value. From your example, you'll end up with a variable named spring_profiles_active with a value of cloud. Plus the other two you have defined.
JAVA_OPTS is a special env variable for the Java buildpack. Whatever you put into JAVA_OPTS will be included in the start command for your application. It is an easy way to add additional arguments, system properties and configuration flags to the JVM.
Please note, at least in the example above, the spacing is wrong on your env: block. It's all the way to the left, but the env:should be indented two spaces. Then each env variable defined under theenv:` block should be indented two more spaces for a total of four spaces. YAML is very picky about spaces and indentation. When in doubt, use a YAML validator to confirm your YAML is valid.
Related
After deployment, is there a way to inspect the process.env variables on a running cloud run service?
I thought they would be available in the following page:
https://console.cloud.google.com/run/detail
Is there a way to make them available here? Or to inspect it in some other way?
PS: This is a Docker container.
I have the following ENV on my Dockerfile. And I know they are present, because everything is working as it should. But I cannot see them in the service details:
Dockerfile
ENV NODE_ENV=production
ENV PROJECT_ID=$PROJECT_ID
ENV SERVER_ENV=$SERVER_ENV
I'm using a cloudbuild.yaml file. The ENV directives are present in my Dockerfile, and they are being passed to my container. Maybe I should add env to my cloudbuild.yaml file? Because I'm using --substitutions on my gcloub builds sumbmit call and they are passed as --build-arg to my Docker build step. But I'm not declaring them as env in my cloudbuild.yaml.
I followed the official documentation and set the environment variables on a Cloud Run service using the console.Then I was able to list them on the Google Cloud Console.
You can set environment variables using the Cloud Console, the gcloud
command line, or a YAML file when you create a new service or deploy a
new revision:
With the help of #marian.vladoi's answer. This what I've ended up doing
In my deploy step from cloudbuild.yaml file:
I added the --set-env-vars parameter
steps:
# DEPLOY CONTAINER WITH GCLOUD
- name: "gcr.io/google.com/cloudsdktool/cloud-sdk"
entrypoint: gcloud
args:
- "beta"
- "run"
- "deploy"
- "SERVICE_NAME"
- "--image=gcr.io/$PROJECT_ID/SERVICE_NAME:$_TAG_NAME"
- "--platform=managed"
- "--region=us-central1"
- "--min-instances=$_MIN_INSTANCES"
- "--max-instances=3"
- "--set-env-vars=PROJECT_ID=$PROJECT_ID,SERVER_ENV=$_SERVER_ENV,NODE_ENV=production"
- "--port=8080"
- "--allow-unauthenticated"
timeout: 180s
Currently our singleton application including 5 containers goes through AWS pipeline into code build and then code deploy into ECS services. During codebuild base on an ENV set in codebuild $Stage it can be dev, prod or staging and loads a specific config file for which contains all the ENV variables each container needs. See below:
build:
commands:
#Get commit id
- "echo STAGE $STAGE"
- "export STAGE=$STAGE"
#Assigning AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY needs to be done in two steps, otherwise it ends up in "Partial credentials found in env" error
- "export ANSIBLE_VARS=\"\
USE_EXISTING_VPC=true \
DISABLE_BASIC_AUTH=true\""
- "export DOCKER_ARGS=\"-e COMMIT_ID=$GIT_COMMIT -e APP_ENV=$STAGE
Problem 1: is these config files are within the repo and anybody can modify them. So there are lots of human errors like the production redirect Url is pointing to the wrong place, or new ENV is not set.
So I want to move away from loading different config files and move ENV variables to AWS to handle. Something like during code build it will load from parameter store. Is this correct way?
Problem 2 is there are lots of ENV variables, is the only option to list them one by one in the CloudFormation template ? Are there any other better way to load all of ENV variable into DOCKER_ARG from above build command ?
I have a v3 app that I want to deploy to 2 different environments. The app name and some definitions vary from env to env, but the structure of the manifest is the same. For example:
# manifest_test.yml
applications:
- name: AppTest
processes:
- type: web
command: start-web.sh
instances: 1
- type: worker
command: start-worker.sh
instances: 1
# manifest_prod.yml
applications:
- name: AppProd
processes:
- type: web
command: start-web.sh
instances: 3
- type: worker
command: start-worker.sh
instances: 5
Instead of keeping duplicate manifests with only minor changes in variables, I wanted to use a single manifest with variable substitution. So I created something like this:
# manifest.yml
- name: App((env))
processes:
- type: web
command: start-web.sh
instances: ((web_instances))
- type: worker
command: start-worker.sh
instances: ((worker_instances))
However, it seems like cf v3-apply-manifest doesn't have an option to provide variables for substitution (as cf push did).
Is there any way around this, or do I have to keep using a separate manifest for each environment?
Please try one of the cf v7 cli beta releases. I didn't test it but the output from cf7 push -h has a flag for using --vars and --vars-file. It should also use the v3 APIs so it will support things like rolling deploy.
For what it's worth, if you're looking to use CAPI v3 features you should probably use the cf7 beta releases going forward. That is going to get you the latest and greatest support for the CAPI v3.
Hope that helps!
I am using the udeploy cloudfoundry plugin to push applications to cloudfoundry
How can I set the enviornment variables in cloud foundry from udeploy
Environment variables can be set in your cloud foundry manifest file, manifest.yml using the env: block. For example:
env:
http_proxy: http://proxy.example.com:8080
applications:
...
If the value of the environment variable is dynamic, you can use a token:
env:
http_proxy: #PROXY_SERVER_PORT#
applications:
...
And use a "replace tokens in manifest file" step in your Urban Code deploy flow.
I need to set up consumer key and secrets for Github, Twitter and Facebook.
On version 1 of Cloud Foundry you could do vmc env-add NAME=VALUE
Now with the cf gem I see I can do cf env but thats it.
I also tried setting a .env file and repushing with no success
In addition, you can set environment variables in an application manifest file.
Here is an example of how to do so (see the env section of the manifest with name/value pairs)
---
applications:
- name: app1
env:
ENV_VAR_1: MYVALUE
ENV_VAR_2: ZZZ
It looks like you can do a cf set-env (https://github.com/cloudfoundry/cf/blob/master/lib/cf/cli/app/env.rb). You can also always do a cf help --all, which will show you all the commands you can use.