I am attempting to launch a NodeJS app on AWS direct link to guide here:
https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/create_deploy_nodejs_express.html
Screen capture:
When running the git commit -m "First express app" command I always get this error (everything else works fine up until that point)
ERROR: This branch does not have a default environment. You must
either specify an environment by typing "eb deploy my-env-name" or set
a default environment by typing "eb use my-env-name".
If you have overcome a similar experience or can shed light it is more welcome.
Here is my solution
I had the environment in my config but had to call it
inside .ebextensions/config.yml is the following:
branch-defaults:
default:
environment: node-express-env
group_suffix: null
global:
application_name: my_app_name
branch: null
default_ec2_keyname: null
default_platform: node.js
default_region: us-east-2
include_git_submodules: true
instance_profile: null
platform_name: null
platform_version: null
profile: eb-cli
repository: null
sc: git
workspace_type: Application
As such when I modified my command from
eb deploy
to
eb deploy node-express-env
it worked.
There is more information on the AWS docs:
https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/eb-cli-troubleshooting.html
Solution: Run eb list to see a list of available environments. Then run eb use env-name to use one of the available environments.
Related
If you uses the AWS console or even the command line, you won't get any issue in setting a default keypair to your Elasticbeanstalk environment.
But you do if using boto3.
Surprisingly, there's no any single mention about setting a keypair in the official boto3 documentation for elasticbeanstalk: https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/elasticbeanstalk.html.
Tried also to create a zip file containing the most basic files to make a simple website works. And supposedly, I can set a keypair name in the .elasticbeanstalk/config.yml". I did in this way:
branch-defaults:
default:
environment: app10-env
group_suffix: null
global:
application_name: app10
branch: null
default_ec2_keyname: main4
default_platform: PHP 7.4 running on 64bit Amazon Linux 2
default_region: us-east-1
include_git_submodules: true
instance_profile: null
platform_name: null
platform_version: null
profile: null
repository: null
sc: null
workspace_type: null
Yes, the "main4" exists in my AWS account. But creating an environment to my application with a zip containing it, it seems that it have no effect at all. After my environment has sucessfully deployed, I can check afterwards through console and see that have no keypair setted to environment. I need to go to a further step on console to set the keypair and await a new environment deployiment to perform the update.
Is there a real issue with the boto3 elasticbeanstalk when dealing with environment keypairs or I am doing something wrong?
I would set the OptionSettings when calling create_environment or include the keyname in the .ebextensions. Boto3 is not reading the EB CLI default config you are using i guess.
Refs
https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/elasticbeanstalk.html#ElasticBeanstalk.Client.create_environment
https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/environment-configuration-methods-before.html
Option to set
Namespace: aws:autoscaling:launchconfiguration
Option Names: IamInstanceProfile, EC2KeyName, InstanceType
The response of #f7o is not accurate, but helped to solve the problem.
There's no option for setting an keypair using "create_environment" command from boto3 client. Tried to use a "EC2KeyName", but it returned an exception of invalid value.
But using the "ebextensions" do the work. If someone else are interested in do the same task that I am, so everything that is needed to do is create a folder called ".ebextensions" with a file called "customkey.config" (the file name can be anything, but must be suffixed with .config), and with the following content:
option_settings:
- namespace: aws:autoscaling:launchconfiguration
option_name: EC2KeyName
value: <your_keypair_name>
I am trying to deploy a Node.js application on windows EC2 instances. Deployment finishes successfully but node server is not started automatically on those instances. I've to login to each instance to run command node app.js to start node server. I tried to include this command in appspec.yml file but then I got below error,
LifecycleEvent - ApplicationStart
Script - node_start.bat
[stdout]
[stdout]C:\Windows\system32>cd C:/host/
[stdout]
[stdout]C:\host>npm start
[stderr]'npm' is not recognized as an internal or external command,
[stderr]operable program or batch file.
My appspec.yml file is as below,
version: 0.0
os: windows
files:
- source: app.js
destination: c:\host
- source: package.json
destination: c:\host
- source: \node_modules
destination: c:\host\node_modules
- source: node_start.bat
destination: c:\host
- source: before_install.bat
destination: c:\host
hooks:
AfterInstall:
- location: before_install.bat
timeout: 300
ApplicationStart:
- location: node_start.bat
timeout: 300
Node is already installed on those two instances and Path variable is also properly set. Logging manually to those servers and running command npm start works perfectly fine. It fails only though AWS Code deploy.
I want to introduce AWS Lambda function also after this step to do health check.
Any help to resolve this issue would be greatly appreciated.
The issue isn't really related to CodeDeploy. CodeDeploy simply runs the script that you give it; in your case, node_start.bat. Perhaps, this question answers the issue that you're really having. CodeDeploy has no knowledge of your application unless you tell it.
You will likely either need to edit node_start.bat or your environment so that npm is a valid command.
Here are a couple of suggestions to help your case:
Test your appspec and scripts
You can test your appspec.yml and related scripts using the CodeDeploy local CLI, which comes with the agent.
Validate that your service is running
Obviously, it's not awesome if your deployment succeeds, but your application is not actually running. However, you can use the ValidateService lifecycle hook to confirm that your application is actually running or any other validation. You can include a script that can see that the process is running, confirm that no errors are getting logged, run tests, or whatever else you might want.
I'm using Windows 7x64, gcloud installed version
Google Cloud SDK 0.9.71
app 2015.07.24
app-engine-java 1.9.24
app-engine-python 1.9.24
app-engine-python-extras 1.9.21
bq 2.0.18
bq-win 2.0.18
core 2015.07.24
core-win 2015.07.24
gcloud 2015.07.24
gsutil 4.13
gsutil-win 4.13
preview 2015.07.24
windows-ssh-tools 2015.06.02
I'm trying to run on preview and deploy the tutorial example from here. Note that app.yaml from this example has "nodejs" set as runtime.
After running command
gcloud preview app run --host localhost:8080 app.yaml
I get
RuntimeError: Unknown runtime 'nodejs'; supported runtimes are 'custom', 'go', 'java', 'java7', 'php', 'php55', 'python, 'python27', 'vm'.
If I put "vm" for runtime it wants to use docker, which doesn't work for me either and I wanted to use the option to do this without docker anyhow.
If I put "custom" for runtime in yaml file I get:
ValueError: The --custom_entrypoint flag must be set for custom runtimes
Example given in the help output for this switch is the following
--custom_entrypoint="gunicorn -b localhost:{port} mymodule:application"
I tried with this, best guess
gcloud preview app run --custom_entrypoint="nodejs -b localhost:{8080} mymodule:application" app.yaml
and got this
ERROR: Argument [--custom_entrypoint=nodejs -b localhost:{8080} mymodule:application] is not a valid deployable file.
ERROR: (gcloud.preview.app.run) Errors occurred while parsing the App Engine app configuration.
Thanks for your time.
The gcloud command seems to be undergoing some changes, so this question seems no longer valid, since we're meant to run dev_appserver.py instead of gcloud to run devserver processes; you can also just straight-up run the node server, or even use docker to build the image from your dockerfile and run that as a container.
If running from dev_appserver.py, make sure you have runtime: custom and a Dockerfile sourcing FROMgcr.io/google_appengine/nodejs, since dev_appserver.py currently raises:
RuntimeError: Unknown runtime 'nodejs'; supported runtimes are 'custom', 'go', 'java', 'java-compat', 'java7', 'php55', 'python', 'python-compat', 'python27'.
I'm using NPM's scripts.postinstall to build our application using GulpJS when we push it to Heroku:
"postinstall": "./node_modules/.bin/gulp build --require coffee-script/register"
I want to be able to set an environment variable at this time with the value of the commit hash. This will then be referenced in files as a cachebuster, e.g.:
<script type="text/javascript" src="/index.{{ process.env.commit }}.js"></script>
I can use git-rev to easily get this value asynchronously but I want it stored on an environment level. How can I set a custom Node environment variable?
If I'm going about this the wrong way and there's a better solution please let me know (I can only find methods to set NODE_ENV and not the process.env object itself).
You cannot do this via a postinstall script: the heroku command won't be available in the build environment. You can create your own lightweight deployment script that runs the command on your machine when a successful build occurs however:
#!/bin/sh
git push heroku master && heroku config:set COMMIT=$(git rev-parse --short HEAD)
To note, I got confirmation of this from Heroku support directly. This was their response:
There isn't an installation of heroku toolbelt on the slug compiler. If you need to set an environment variable as part of the push then you'll have to do it on your machine rather than the Heroku compiler.
Solution I've found is to use the heroku config system to set custom environment variables:
git = require "git-rev"
exec = require "exec-sync"
gulp.task "commit", ->
git.long (hash) ->
exec "heroku config:set COMMIT=#{ hash }"
Needs further testing but for now it works (also, because the command is run on the server there's no need to use heroku config:push).
You can now add this metadata with this labs feature from heroku !
heroku labs:enable runtime-dyno-metadata -a <app name>
I have a few apps on Heroku. All of them use GruntJS to build assets and deploy to S3. One app has been working fine for quite some time.
The other apps have a problem where I can not read my config variables from the Gruntfile. When I use Heroku's toolbelt to view my setup, I see:
$ heroku config --app mydevapp --account personal
=== mydevapp Config Vars
AWS_ACCESS_KEY: #########
AWS_BUCKET: #########
AWS_SECRET_KEY: #########
BUILDPACK_URL: https://github.com/ddollar/heroku-buildpack-multi.git
DATABASE_URL: #########
PAPERTRAIL_API_TOKEN: #########
TEST: test
Which is great. However none of these variables are available to me from Grunt. When I console.log(process.env) from the Gruntfile, I see:
{ GEM_HOME: '/tmp/build_e26d1d60-d447-40d8-b09b-02d3758a6027/.gem/ruby/1.9.1',
SHELL: '/bin/bash',
SSH_CLIENT: '10.207.46.127 55868 50678',
GROUP: 'production',
DEPLOY: 'production',
STACK: 'cedar',
SHLVL: '3',
HOME: '/app',
CPPPATH: '/tmp/node-node-hP8q/include',
_: '/tmp/build_e26d1d60-d447-40d8-b09b-02d3758a6027/node_modules/grunt-cli/bin/grunt'
}
There are some other vars in there, but I'm not sure what is safe to show. I don't see ANY of my config vars listed.
I have no idea what the difference is between my working app, and the two apps that don't have config vars in the process.env variable.
I've read that using Grunt in this manner isn't really the best idea, but it is what we have setup. Of course that could change if need be.
Any ideas? Is there anything I need to clarify?
Heroku does not expose the config variables to the build stage by default. It you want this, you'll have to enable the user-env-compile lab by issuing:
heroku labs:enable user-env-compile -a myapp
Docs: https://devcenter.heroku.com/articles/labs-user-env-compile
2017 Update:
Its seems you should use the ENV_DIR argument.
According to doc:
ENV_DIR is a directory that contains a file for each of the
application’s configuration variables. Config vars are made available
as environment variables during execution of commands specified in the
Procfile, as well as when running one-off processes.
Check the bin/compile section for further details
Here is a snippet to extract the config vars in the build phase:
export_env_dir() {
env_dir=$1
whitelist_regex=${2:-''}
blacklist_regex=${3:-'^(PATH|GIT_DIR|CPATH|CPPATH|LD_PRELOAD|LIBRARY_PATH)$'}
if [ -d "$env_dir" ]; then
for e in $(ls $env_dir); do
echo "$e" | grep -E "$whitelist_regex" | grep -qvE "$blacklist_regex" &&
export "$e=$(cat $env_dir/$e)"
:
done
fi
}
For me its seems an overkill - happy to hear your thoughts.