I'm trying to write a manifest for JPS deployment of an Jelastic application.
Creating nodes and deploying webapps works fine but I can't create a database and load a sql dump into it using the manifest directives.
My configs section looks like this:
"configs": [
{
"nodeType": "postgres9",
"restart": false,
"database": [{
"name": "somedbname",
"user" : "someusername",
"dump": "http://www.somehost.de/jelastic/somedump.sql"
}]
},
...
]
...
It seems that the database section is completely ignored.
Any ideas?
Likely you have an extra square brackets around database object definition, i.e. you must have "database" : { ... }, instead of "database" : [{...}]
Also I can suggest you to review an example from Cyclos. Their idea is to download an executable bash script which will be started by cron and do all the things required for setting the database up, including adding of a new user, extensions etc.
Best regards.
Related
I would like to provide a button from github to directly deploy an app.
Its a go application which serves some website.
Now for persistent data it requires an addon "Heroku Postgres".
I tried defining a heroku.yml with:
setup:
addons:
- plan: heroku-postgresql
I tried app.json with:
{
"addons": ["heroku-postgresql:hobby-dev"]
}
But it does nothing at all, it never adds the addon. I know I can add it manually through the website or CLI, but I want a fully automatic way - if that is possible.
It should look something like this
"addons": [
{
"plan": "heroku-postgresql",
"options": {
"version": "12"
}
}
]
Example app.json from heroku
When a build a conda environment like this
conda create --prefix env python=3.6.5
Some absolute paths appear in some json files in the conda-meta folder. How can I avoid it? I just want to use relative paths here or I just want to hide them completely. Is there a way to achieve this? Are they mandatory? See extracted_package_dir, source or package_tarball_full_path attributes:
{
"arch": "x86_64",
"build": "py36_0",
"build_number": 0,
"channel": "https://repo.anaconda.com/pkgs/main/win-64",
"constrains": [],
"depends": [
"python >=3.6,<3.7.0a0"
],
"extracted_package_dir": "C:\\Users\\UserName\\AppData\\Local\\conda\\conda\\pkgs\\certifi-2019.3.9-py36_0",
"features": "",
"files": [
"Lib/site-packages/certifi-2019.03.09-py3.6.egg-info",
"Lib/site-packages/certifi/__init__.py",
"Lib/site-packages/certifi/__main__.py",
"Lib/site-packages/certifi/__pycache__/__init__.cpython-36.pyc",
"Lib/site-packages/certifi/__pycache__/__main__.cpython-36.pyc",
"Lib/site-packages/certifi/__pycache__/core.cpython-36.pyc",
"Lib/site-packages/certifi/cacert.pem",
"Lib/site-packages/certifi/core.py"
],
"fn": "certifi-2019.3.9-py36_0.tar.bz2",
"license": "ISC",
"link": {
"source": "C:\\Users\\UserName\\AppData\\Local\\conda\\conda\\pkgs\\certifi-2019.3.9-py36_0",
"type": 1
},
"md5": "e1faa30cf88c0cd141dfe71e70a9597a",
"name": "certifi",
"package_tarball_full_path": "C:\\Users\\UserName\\AppData\\Local\\conda\\conda\\pkgs\\certifi-2019.3.9-py36_0.tar.bz2",
"paths_data": {
"paths": [
[...]
If I remove the whole folder the environment become useless and I cannot activate it anymore in order to install, update or remove new packages.
I want to do this to encapsulate the environment in one application and I do not want to have my original absolute paths in the computer of the final user.
My Use Case
I am developing an electron app that uses a tornado server (that uses python)
Currently I am using electron-builder to add the environment to the installer and works pretty well, but one drawback is the conda-meta folder I commented above. What I do now is to remove it manually when I want to make an installer.
That will probably break conda. It's not written to treat those as relative paths. If you told us more about your use case, maybe we could help. Are you trying to redistribute an installed environment? Have you see the "constructor" or "conda-pack" projects?
Finally the best solution I found was to ignore the folder when creating the final installer with electron-builder.
So I have applied the directive extraResources to add the conda environment except the folder conda-meta. And I have added the filter "!conda-meta${/*}", the meaning is explained here
Remember that !doNotCopyMe/**/* would match the files in the doNotCopyMe directory, but not the directory itself, so the empty directory would be created. Solution — use macro ${/*}, e.g. !doNotCopyMe${/*}.
The result in the package.json file:
"extraResources": [
{
"from": "../env",
"to": "env",
"filter": [
"**/*",
"!*.pyc",
"!conda-meta${/*}"
]
}
],
I am setting up a Heroku pipeline and I want to add the "add-on" attribute however I did not see them be applied to my environment.
The format of the add ons block is:
"addons": [
"sendgrid",
{
"plan": "deployhooks:http",
"as": "SLACK-ENG-STATUS",
"options": {
"url": "THIS IS A RANDOM URL"
}
}
],
Is that the correct syntax to create the add-on? I do not see the configuration in the staging app when I directly deploy to it.
Do you expect your addon to be created on deploy? Because that is not how the app.json works. The app.json only created your addons for:
Review apps (https://devcenter.heroku.com/articles/github-integration-review-apps#app-json)
When you use the platform API to create your app (https://devcenter.heroku.com/articles/setting-up-apps-using-the-heroku-platform-api), including through the Heroku Button
If you already have an existing app, entries in the app.json will not modify it on deploy.
I'd like to use an executable WAR file in a production environment. I also have several Node.js apps in the same environment for which I use the PM2 process manager to manage the whole lifecycle of (startup on boot, restart on failure, etc.).
PM2 is capable of handling java jar files as well (see e.g. https://stackoverflow.com/a/41702429/1266411 for details) so it would make sense to use PM2 for this purpose too, but I don't see how a JHipster executable WAR can be configured this way (to be used standalone, without a container).
Any suggestions?
This is my working example. FYI.
{
"apps": [{
"name": "War",
"cwd": ".",
"args": [
"-jar",
"/path/to/your.war"
],
"env": {
},
"script": "/usr/bin/java",
"node_args": [],
"log_date_format": "YYYY-MM-DD HH:mm Z",
"exec_interpreter": "none",
"exec_mode": "fork"
}]
}
I am using an instance of MongoDB with just one node. I would like to write a web service that fsyncs the data files and zips them into a backup folder.
Ideally, I would get the location of the data directory programatically (rather than reading a config file) so I can easily port this from a development to a production machine, where the installation paths differ. Is there any way to do this using the Java driver?
Try using use admin
db.runCommand({getCmdLineOpts: 1}) as outlined here and then playing with the returned data.
Example return data is
{
"argv" : [
"mongod",
"--port",
"6669",
"--dbpath=c:\\data\\mongo2",
"--rest"
],
"parsed" : {
"dbpath" : "c:\\data\\mongo2",
"port" : 6669,
"rest" : true
},
"ok" : 1
}
You could use mongoexport to get the data; run it from the production machine and specify the host/port/collection of the development machine. The data can be imported to the production machine using mongoimport.