I am currently trying to run jhipster-registry in dev profile to serve the configurations to a jhipster microservice application.
I've followed this official jhipster registry doc and:
have built it from sources, and launched it as follow:
./jhipster-registry-3.0.0.war --spring.profiles.active=dev
And as the doc states, i have put the central-config directory containing <mymicrosericeappname>-dev.yml alongside the jhipster-registry generated war file.
When i launch jhipster-registry, everything is ok,
but when i run my microservice application, it connects to the registry (i can see it in the jhipster-registry dashboard), but i realize that it is reading the application-dev.yml file located at src/main/resources/config/ inside the microservice app.
I dont know if i misplaced the central-config folder...
That said, i really need to know what's wrong.
Thanks
The config directory is specified in bootstrap.yml in search-locations property.
spring:
cloud:
config:
server:
native:
search-locations: file:./central-config
Rather than specifying a relative path (relative to where you launched the regsitry from), you may want to specify an absolute path:
search-locations: file:/home/something/central-config
Also rather than using dev profile, you can use prod with native :
./jhipster-registry-3.0.0.war --spring.profiles.active=prod,native
Thanks to #GaelMarziou, his answer helped me found why the central-config was not being rode.
In fact the Spring Cloud Config bootstrap configuration for the "dev" profile bootstrap.yml file gives this:
cloud:
config:
server:
git:
uri: https://github.com/jhipster/jhipster-registry-sample-config
native:
search-locations: file:./central-config
So each time i ran jhipster-registry, it was pointing the git repo and not the central-config directory.
To get it work, i had to launch the registry in dev,native profile :
./jhipster-registry-3.0.0.war --spring.profiles.active=dev,native
Nevertheless the documentation states this:
Using the dev profile will run the JHipster Registry with the dev and the native profiles.
Which is not really true... considering my struggling.
Related
I am trying to push Kibana
https://www.elastic.co/products/kibana
to Bluemix PaaS via cloudfoundry. At cf push i get this error
Error uploading application.
GetFileAttributesEx C:\Users\asd\qwe\zxc\installedPlugins\shield\node_modules\eslint\node_modules\file-entry-cache\node_modules\flat-cache\node_modules\del\node_modules\globby\node_modules\glob\node_modules\inflight\node_modules\wrappy\package.json: The system cannot find the path specified.
i can see that the package.json is actually present at that path! How do i resolve this?
cf --version
cf version 6.12.4-b4b6af1-2015-09-18T10:55:12+00:00
The error is due to the file path being too long. Add the node_modules directory to a .cfignore file in the app's root directory and then push again. The node_modules won't be uploaded and will instead be installed as part of the staging process.
See https://github.com/IBM-Bluemix/nodejs-cloudant/blob/master/.cfignore for an example .cfignore.
You could also switch to npm v3 which keeps the node_modules directory flatter, but you still wouldn't normally push it with your app.
I know that there's couple posts like this one, but solution of any of them works for me.
Here is what I receive when I go for git push heroku master:
Please support. Ignoring node_modules is not working.
Docpad app - package.json file is updated according to docpad's manual.
I also have Procfile set up as in the link above.
PS. I have tried to deploy docpad app via openshift, but while Im going with manual from http://docpad.org/docs/deploy/ I receive error at step 5.
The application 'appname' is configured for git reference deployments but the
artifact provided ('https://github.com/myusername/appname#master') is a url.
Please provide a git reference to deploy (branch, tag or commit SHA1) or
configure your app to deploy from binaries with 'rhc configure-app appname
--deployment-type binary'.
If I configure myapp to deployment-type binary it isnt working neither.
The plugin which heroku tries to install returned 404 and the installation fails due to that.
Verify that the plugin is indeed public and not something you have wrote or used locally.
There is no package with this name hosted on the registry you use.
Remove the line with "docpad-plugin-blah": "2" from your package.json file. That line was provided in the docs simply to show you how to install plugins, but there's no such plugin as blah.
"dependencies": {
"docpad": "6"
},
I strongly recommend that you read through the Getting Started on OpenShift to get an overview of the development workflow using Git.
That being said, and if you really meant to use git reference deployments and you know why you are using them, then read through the Managing Deployments section on the developers page of OpenShift and find out how to properly set up git reference deployments. For instance, 'https://github.com/myusername/appname#master' is not a valid git url and therefore it cannot be cloned.
I'm trying to follow the tutorial noted below:
http://www.ibm.com/developerworks/cloud/library/cl-bluemix-nodejs-app/
But when I push my app, I see the following:
Using manifest file /mytests/bluemix-node-mysql-upload/manifest.yml
Updating app jea-node-mysql-upload in org jea68#gmail.com / space dev as jea68#gmail.com...
OK
Uploading jea-node-mysql-upload...
Uploading app files from: /mytests/bluemix-node-mysql-upload/app
Uploading 53.6K, 11 files
Done uploading
OK
FAILED
Could not find service mysql-database to bind to jea-node-mysql-upload
Is there a problem with the node.js buildpack or is the documentation faulty?
I've been able to push apps to Node.js without any problems this morning. The documentation assumes the user knows that the service has already been created. The manifest.yml included in the github repo of the tutorial defines a service (mysql-database) that has not been created. Run the following command to create the service:
$ cf create-service mysql 100 jea-mysql-node-upload-service
Then modify the manifest.yml to include:
services:
- jea-mysql-node-upload-service
Alternatively, since you already have an app, you can bind the application to the service by running the following:
$ cf bind-service jea-node-mysql-upload jea-mysql-node-upload-service
$ cf start jea-node-mysql-upload
It looks like a fault in the documentation. If you look at Step 2 part 3 it says to create the my-sql service using this command:
cf create-service mysql 100 mysql-node-upload
which will name the service instance as mysql-node-upload, however the manifest.yml file that you cloned from github contains the service name of just mysql-service. It is the manifest.yml file that links the app with the service instance.
The options are either the change the manifest.yml file to be the correct name of your mysql service instance or recreate the mysql service instance with the name that is in your manifest.yml.
We have a nodejs project running on Amazon Elastic Beanstalk that uses private modules that we host using nodejitsu's private npm registry.
However getting access to the private npm registry from the elastic instances hasn't been straightforward and is not documented well.
What is the best way to get this access set up?
None of the other answers were working for me. After hours of hair pulling, we finally figured it out. The solution that worked is almost the same as the other answers but with a very minor tweak.
Set an NPM_TOKEN environment variable on Elastic Beanstalk under Configuration > Software Configuration > Environment Properties.
Create a .ebextensions/npm.config file. (The name does not have to be 'npm'.)
Put this content into the file:
files:
"/tmp/.npmrc":
content: |
//registry.npmjs.org/:_authToken=${NPM_TOKEN}
Note that it uses ${NPM_TOKEN} and not $NPM_TOKEN. This is vital. Using $NPM_TOKEN will not work; it must have the curly braces: ${NPM_TOKEN}.
Why are the curly braces needed? No idea. In shell/POSIX languages, ${VAR} and $VAR are synonymous. However, in .npmrc files (at the time of this writing), variables without the curly brackets are not recognized as variables, so npm must be using a slightly different syntax standard.
UPDATE
Also, this has worked for us only on new or cloned environments. For whatever reason, environments which were not initialized with a /tmp/.npmrc will not read it in any future deployments before running npm install --production. We've tried countless methods on 4 different apps, but cloning and replacing an environment has been the only method which has worked.
So, we managed to get this working by using the npm userconfig file. See the doc page for npmrc for more info.
When a nodejs application is being deployed to Elastic Beanstalk, the root user runs npm install. So you will need to write the root's npm userconfig file, which is at /tmp/.npmrc.
So if you add a file called private_npm.config (or whatever name you choose) to your .ebextensions folder with all the information needed, you will be good to go. See Customizing and Configuring AWS Elastic Beanstalk Environments for more info.
So here is what my file looks like to use nodejitsu private registry.
.ebextensions/private_npm.config:
files:
#this is the npm user config file path
"/tmp/.npmrc":
mode: "000777"
owner: root
group: root
content: |
_auth = <MY_AUTH_KEY>
always-auth = true
registry = <PATH_TO_MY_REGISTRY>
strict-ssl = true
email = <NPM_USER_EMAIL>
Using an .npmrc within the project also works. For example...
.npmrc
registry=https://npm.mydomain.com
You may want to .gitignore this file if you include an _authToken line but make sure you don't .ebignore it so it's correctly bundled up with each deployment. After trying a few things unsuccessfully, I came across this post which made me realize specifying it locally in a project is possible.
The answer above as a step in the right direction, but the permissions and owner did not work for me. Managed to get it to work with the following combination:
files:
#this is the npm user config file path
"/tmp/.npmrc":
mode: "000600"
owner: nodejs
group: nodejs
content: |
_auth = <MY_AUTH_KEY>
always-auth = true
registry = <PATH_TO_MY_REGISTRY>
strict-ssl = true
email = <NPM_USER_EMAIL>
Place the below within your .ebextensions/app.config.
files:
"/tmp/.npmrc":
mode: "000777"
owner: root
group: root
content: |
//registry.npmjs.org/:_authToken=$NPM_TOKEN
Where NPM_TOKEN is an environment variable with the value of your actual npmjs auth token.
Note that environment variables within elasticbeanstalk can and should be set from within the AWS console Elasticbeanstalk software configuration tab.
AWS Elasticbeanstalk Configuration
In new Elastic Beanstalk Linux 2 Platforms, none of these solutions work (apart from the .npmrc file solution that works but has its issues when using them in development evironments due to the requirements that all developers have their ${NPM_TOKEN} Env Var defined in their own environments).
The reason is that the /tmp/.npmrc location no longer works.
Option 1
You have to change the .ebextensions/npm.config file to this new format:
files:
#this is the npm user config file path
"/root/.npmrc":
mode: "000777"
owner: root
group: root
content: |
_auth= ${NPM_TOKEN}
registry = https://{yourprivatenpmrepository.com}/
Option 2
Add a custom .npmrc_{any-suffix} to the root of your app and create a prebuild hook to rename it before Beanstalk executes the npm install so that it can use your private repository configuration:
Add the following file (path from your app root) .platform/hooks/prebuild/01_set_npmrc.sh with the following content:
#!/bin/bash
#Copy and rename .npmrc_beanstalk to .npmrc
mv .npmrc_beanstalk .npmrc
Create an .npmrc_beanstalk file in your root with the following content (modify it depending on your private npm config):
_auth= ${NPM_TOKEN}
registry = https://{yourprivatenpmrepository.com}/
Chmod the hook file so that it has the necessary exec permissions when uploaded to EB: chmod +x .platform/hooks/prebuild/01_set_npmrc.sh
Re-deploy using EB CLI and you are done!
With modern platforms, you no longer need to do this via .ebextensions
You can simply create a .npmrc file at the root of your deployment package, alongside your package.json with the following line:
//registry.npmjs.org/:_authToken=${NPM_TOKEN}
Using this method, you can create an environment variable named NPM_TOKEN in your AWS console so you don't have to store the token in your repo.
Structure:
~/your-app/
|-- package.json
|-- .npmrc
I added a scripts.config file to .ebextensions at the root of my Node app deployed in beanstalk.I did not see the tags for the EC2 instances in the console. Nor did I see any mention of 1_add_tags in beanstalk logs. What did I do wrong and how do I find out if the commands in the script.config were called at all!
The config file in .ebextensions is as follows ....
01_add_tags:
command: ec2-create-tags $(ec2-metadata -i | cut -d ' ' -f2) --tag Environment=Production --tag Name=Proxy-Server --tag Application=something
env:
EC2_HOME: /opt/aws/apitools/ec2
EC2_URL: https://ec2.ap-southeast-2.ama...
JAVA_HOME: /usr/lib/jvm/jre
PATH: /bin:/usr/bin:/opt/aws/bin/
Cheers,
Prabin
Amazon's answer to the problem. (This worked for me) ...
You can utilise the ebextensions to execute certain commands on instance boot.
Supposing that you want to implement this on Linux based containers. I have formulated a sample config file for you and attached to this case.
Please follow below guidelines :
In the AWS Management console, check the IAM Role/Instance profile used by beanstalk. By default it uses "aws-elasticbeanstalk-ec2-role". Add permissions for this role to create new tags (ec2:CreateTags).
If you do not have ".ebextensions" folder at the root of your application or the "WEB-INF" folder, then create the folder.
Modify the key value pairs in the config file. Multiple pairs are separated by a space.
A sample snippet is as below:
{
"container_commands": {
"01_add_tags": {
"command": "aws ec2 create-tags --resources $(GET http://169.254.169.254/latest/meta-data/instance-id) --tags Key=ClientName,Value=testClient Key=NewTag,Value=new-value --region us-east-1"
}
}
}
Add the modified config file in the ".ebextensions" folder.
Upload this version to beanstalk. It should launch new instances and execute the config file.
Please give it sometime, preferably till the instances pass EC2 instance status checks. Refresh the page for the additional tags to be displayed.
Please note that we are using "Container_commands" instead of "Command" used in the blog.
Container Commands run after the application and web server have been set up and the application version file has been extracted, but before the application version is deployed. This is important as these commands have access to environment variables such as your AWS security credentials set by the instance-profile.
I would recommend you to go through the restrictions for AWS Resources tagging mentioned at http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#tag-restrictions
I would like to highlight that maximum number of tags per resource is 10.
Also check the table for tagging support for certain resource. For example, currently tagging is not supported for ELB.
I had the similar problem where I tried to install libjpeg using the ./ebextensions/foo.config file. I tried everything but was never able to find a good solution.
I was able to solve it though, by setting up a completely new Elastic Beanstalk Application and then deploying my same version on the new instance instead. When I did this everything was installed perfectly and working fine.
Check out my answers here:
https://stackoverflow.com/a/23109410/2335675
https://stackoverflow.com/a/23131959/2335675
Hope this fixes your issues as well.