Amplify provides some env vars available during build like AWS_BRANCH_ARN
I want to get them into my app like REACT_APP_ AWS_BRANCH_ARN
But I'm not sure the best practice for doing that... a pre-deploy script that can grab them from the built environment and add them to a .env file?
NOTE: these are not my own custom vars that I could enter via the AWS amplify console, they're amplify-provided vars
CONTEXT: we use PR previews, and I want to automatically have a good env var to get the PR number (used to figure out the backend API URL).
See Amplify Console environment variables:
https://docs.aws.amazon.com/amplify/latest/userguide/environment-variables.html
Related
I'm building a Kotlin console app that's going to be installed in one of my customer servers. The app downloads some data from a REST API. Before pulling the data the app needs to obtain a token by issuing a login request using a username and password.
I'm gonna be packaging the app using The Badass Runtime Plugin with the runtime parameter, which basically creates a folder including my jar, dependencies and a bunch of scripts.
To avoid hard coding the password in the application code I came with the following approach:
I'm going to store the password in an application.properties file and pass the file path to it using an environment variable.
val props = Properties()
props.load(FileInputStream(System.getenv("ECC_CONFIGS_PATH")))
println(props.password)
When installing the app on the client's computer I'm going to create an application.properties file and the required env variable.
Is it a good approach or is it preferable to pass the file path to the application.properties using a -D parameter? In that case, how do you access its value in the application code?
Are there better approaches rather than the app properties?
I've gotten an Amplify project dropped in my lap where the backend environment is deleted (or lost when the project were moved to another account).
I haven't worked with Amplify before, so I'm not sure how "automatic" everything is.
I noticed that the project has a folder called 'amplify-backup' which contain a bunch of json and graphql config files, so I assumed that I could use those somehow to restore the backend environment in AWS, but I can't seem to find any information on how to do so.
There's currently no backend environment in the AWS console and I don't really know which services the backend environment should contain.
Is it possible to restore the backend environment and all the services that the application need or do I need to figure out which services are needed?
If so, any pointers on how to find which services that are used?
If the project files still exist (amplify directory), you may be able to re-create the project with the existing resources.
One idea could be to clone the git repository from when the amplify project files were intact and run amplify init
OR
amplify-backup is generally generated automatically when doing commands with amplify. You could try rename to amplify and run amplify init.
See more here for re-creating an amplify project on another account: https://docs.amplify.aws/cli/migration/cli-migrate-aws-account/
I'm currently developing a simple webapp with seperated frontend (Vue) and backend (quarkus REST API) project. For now, I've setup a MVP, where the frontend is displaying some simple data which is called from the backend. To get a working MVP i need to setup CORS support. However, first i want to explain my setup:
Setup
I'm starting developing environment of my frontend with npm run serve and of my backend with ./mvnw quarkus:dev. Frontend is running on localhost:8081 and backend running on localhost:8080.
Heroku allows to run your apps locally aswell with the command heroku local web. Frontend is running on port 0.0.0.0:5001 and backend on 0.0.0.0:5000.
To achieve this setup i setup two .env files on my frontend which are pointing to my backend api. If i want to work in development mode the file .env.development is loaded:
VUE_APP_ROOT_API=http://localhost:8080
and if i run heroku local web the file .env.local with
VUE_APP_ROOT_API=0.0.0.0:5000
is loaded.
In my backend I've set
quarkus.http.cors=true
in my application.properties.
Now I want to deploy those two projects to heroku and use it in production. Therefore I setup two heroku projects and set a config variable in my frontend project with the following value:
VUE_APP_ROOT_API:https://mybackend.herokuapp.com
Calls from my frontend are successfully working!
Question
For the next step, I want to restrict it more and just enable my frontend to call my API. I know i can set something like
quarkus.http.cors.origins=myfrontend.herokuapp.com
However, I dont know how i could do this on quarkus with different environments (development, local and production)? I've found this link but I don't know how to configure heroku and my backend app correctly. Do i need to setup different profiles which are applied on my different environments? Or is there another solution? Do i need Herokus Config Variables?
Thanks for the help so far!
quarkus.http.cors.origins is overridable at runtime so you have several possibilities.
You could use a profile and have everything set up in your application.properties with %prod.quarkus.http.cors.origins=.... Then you either use -Dquarkus.profile=prod when launching your application or you use QUARKUS_PROFILE=prod as an environment variable.
Another option is to use an environment variable for quarkus.http.cors.origins. That would be QUARKUS_HTTP_CORS_ORIGINS=....
My recommendation would be to use a profile. That way you can safely check that all your configuration is consistent at a glance.
I'm trying to integrate serverless to my circleci workflow.
I tried first adding both, key and secret to AWS permissions, but that did not work.
Then, I added key and secret to Environment variables and in my config file:
sudo npm install -g serverless
sls config credentials --provider aws --key $AWS_ACCESS_KEY_ID --secret $AWS_SECRET_ACCESS_KEY
sls deploy -v
But I see the same error:
Serverless Error ---------------------------------------
You are not currently logged in. Follow instructions in http://slss.io/run-in-cicd to setup env vars for authentication.
Anyone had this issue? I could not find an answer or hint online. Thanks.
This likely only applies to those trying to use Serverless Enterprise with the monitoring & dashboards they have set up. #wintvelt's answer wouldn't work for me because if i deleted the org variable, it would likely break the connection needed for Enterprise. So steps for my CircleCI setup:
In CircleCI, create a Context for each environment with the AWS Key ID and Secret as environment variables (putting them in a context is a nice to have, you could use other methods of making Circle inject environment variables into builds).
In your Serverless Framework dashboard, create a new access key which you will use in Circle.
Create a new environment variable SERVERLESS_ACCESS_KEY with the value from step 2.
I got this idea from reading how Seed.run has users integrate with Serverless. For more info read this link: https://seed.run/docs/integrating-with-serverless-enterprise.
Just checked Circleci stopped supporting AWS Permissions as a configurable option in the settings page.
You need to set the credentials as environment variables for the projects. The credentials should be named exactly AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY.
that's all you need to do. you don't have to do any additional step. I tried this on my project and it worked.
Your deployment step should simply be
sls deploy
As a follow-up to the previous answer: I had exactly the same error.
I took the solution from the chat as a solution.
For me the fixes I applied:
In CircleCI project settings, under "AWS permissions" I added the AWS Access Key ID and Secret Access key
In CircleCI project settings, under "Environment variables", I also added the AWS Access Key ID and Secret Access key
From my serverless.yml file, I deleted the line with org variable
For me, 1. and 2. alone was not enough. I also had to remove the line from my yml file to make deployment via CircleCI work.
For those landing here with the same issue, hope this helps!
I am new to KeystoneJS and I am having a small problem concerning my deployment on Heroku.
This is my website: http://jeroendruwe.herokuapp.com/, when I navigate to the admin section (http://jeroendruwe.herokuapp.com/keystone/signin)
I get the Invalid Cloudinary Config Provided error
Papertrailapp log: http://pastebin.com/Yn8Pdttz
I've read the documentation (http://keystonejs.com/docs/configuration/#services-cloudinary). The weird thing is that when I try one of these (in keystone.js), the whole site stops working:
keystone.set('cloudinary config', { cloud_name: 'my-cloud', api_key: 'abc', api_secret: '123' });
// or
keystone.set('cloudinary config', 'cloudinary://api_key:api_secret#cloud_name' );
So what I've done at the moment is set the property in the keystone.init(...'cloudinary config': 'cloudinary://...'). I've also added the url to the CLOUDINARY_URL environment variable in the .env file
How can I fix this issue?
Can somebody also explain what the variables in the .env file do? There is 1 in the root and another one in the node_modules/dotenv folder, these files are not pushed to git so how do they get used?
Thanks in advance!
First, let me start by answering your last question first. The .env file is used by the dotenv module, which loads the variables/values in the .env file and makes them available to your application in process.env. Make sure you call the .load() method as early as possible in your code.
var dotenv = require('dotenv');
dotenv.load();
You should also know that Heroku has two other means to configure environment variables (See Configuration and Config Variables). One via your application dashboard and another via their CLI.
Using the Heroku Dashboard, just fill in the NEW_KEY and NEW_VALUE fields, then press Save.
Using the Heroku CLI, just use the heroku config:set command.
$ heroku config:set CLOUDINARY_URL=cloudinary://api_key:api_secret#cloud_name
Adding config vars and restarting myapp... done, v12
CLOUDINARY_URL: cloudinary://api_key:api_secret#cloud_name
If you're using Heroku, I suggest you use one of these to methods to set the CLOUDINARY_URL for your application in production.
Now back to your original question. This error typically means that there's something wrong with the Cloudinary configuration (i.e. it's either incorrect or completely missing). Without seeing the actual code that you're using it would be impossible to pinpoint the exact problem.
I'm going to assume that your replacing the api_key, api_secret and cloud_name with the actual values. That said, I would still double check to make sure those values are correct.
In my Heroku deployments, I use dovenv to set the environment variables in development, and use the either the Heroku Dashboard or CLI to set them in production.
If you're still having difficulties, please post the actual code your using (omitting your actual api key, of course), including the content of your .env file.