I mean, for example, installing a database using a webserver then deploy the database with my application without more configuration, just a portable database, is it possible? Currently my mongo database is installed and dependent of my computer system, I would make it portable, it is possible to build a database upon my webserver, hence make it portable?
Any hint would be great,
thanks
Related
I'm developing an application that heavily relies on Postgres. Currently, users are required to have Postgres set up and place database credentials in a config file that my app reads.
There are a couple of issues with the approach which I am not entirely happy with:
I can't dictate the version of Postgres to use (they may need a certain version for some other task)
Users have to install a separate piece of software before they can use my application.
They would need to provide database credentials to my app (which they may revoke later)
Potentially issues with database name conflicts
Is it possible to run a standalone version of Postgres i.e running it from a folder and potentially alongside another version of Postgres on the same machine?
My current solution is to run it as a docker instance, this avoids any conflicts with data and permissions but does not solve the problem of needing users to install a separate piece of software first.
The application is completely standalone and single user and there is never a need for a user to interact with the database directly, even actions like taking backups is handled by the app, which internally calls pg_dump
(I would have thought something like this would be possible for the people who develop Postgres - I can't imagine they constantly install and remove the software completely from their system in order to test things.)
We have a cloud-foundry app that is bound to a Postgresql service. Right now we have to manually connect to the Posgresql database with pgAdmin, and then manually run the queries to create our tables.
Attempted solution:
Do a cloud foundry run-task in which I would install
1) Install psql and connect to the remote database
2) Create the tables
The problem I ran into was that cf run-task has limited permissions to install packages.
What is the best way to automate database table creation for a cloud-foundry application?
Your application will run as a non-root user, so it will not have the ability to install packages, at least in the traditional way. If you want to install a package, you can use the Apt Buildpack to install it. This will install the package, but into a location that does not require root access. It then adjusts your environment variables so that binaries & libraries can be found properly.
Also keep in mind that tasks are associated with an application (they both use the same droplet), so to make this work you'd need to do one of two things:
1.) Use multi-buildpacks to run the Apt buildpack plus your standard buildpack. This will produce a droplet that has both your required packages and your app bits. Then you can start your app and kick of tasks to set up the DB.
2.) Use two separate apps. One for your actual app and one for your code that seeds the database.
Either one should work though. Both are valid ways to seed your database. The other option, which is what I typically done, is to use some sort of tool to do this. Some frameworks like Rails, have this built-in. If your framework does not, you could bring your own tool, like Flyway. These tools often also help with the evolution of your DB schema, which can be useful too.
I implemented a server application with Play Framework.
I built native packages for different Operating Systems (Linux, Windows, Mac OS X) with SBT Native Packager.
This application requires a NoSQL Database. In particular, I am using MongoDB. Is there a way to embed MongoDB binary/package in my native package? Is this the best practice? Or do you suggest to install MongoDB and my Play application with two different packages?
If it is not possible / recommended to embed MongoDB in a package, do you suggest another DBMS (for instance Nitrite Database)? Thanks
This is not really best practise. Play has H2 in-memory DB embedded but this is only intended for development (because it is quicker than something that reads/writes to disk as well).
You really want to have your Mongo (or whatever other data store you decide to use) instance running in a different process, and packaged, deployed, stopped, started separately from your Play application.
You could probably figure out how to package it with your Play application and then have some script run during app startup to setup the database and load any existing data in -dbpath ie. whenever you redeploy/restart your application. But then you would have to stop/redeploy your Mongo binaries each time you redeploy a code change. You may update your application several times over a year but you are unlikely going to want to update your Mongo binaries as often. I could go on, but don't do it. It is best practise to manage your data stores separately from your applications.
I'm looking for some suggestions on how I could manage external dependencies when I want to run my Play framework based app locally.
I have a Play based application that connects to a database to look up application data. In order to run this against a specific environment, it is not a problem, but what if say I want to run this locally? With the current setup, if there is no database available, my app would just not start! I mean, without a database running my application also has no meaning as I could not do anything without data!
I'm using MongoDB as my database, so I see the following possibilities to enable running my application locally!
Use in memory mode from MongoDB
Use some sort of docker container to run a MongoDB instance locally
Is there any other possibility that is worth exploring?
We want to restore the database that we have got from the client as backup in our development environment, we are unable to restore the database successfully, can any one help us to know the steps involved in this restore process? Thanks in Advance.
Vijay, if you plan to make a new database out of checkpoints (+journals) made on another (physical) server, then I must disappoint you - it is going to be a painful process. Follow these instructions http://docs.actian.com/ingres/10.0/migration-guide/1375-upgrading-using-upgradedb . The process is basically the same as upgradedb . However, if architecture of the development server is different (say backup has been made on a 32bit system, and development machine is, say POWER6-based) then it is impossible to make your development copy of the database using this method.
On top of all this, this method of restoring backups is not officially supported by Actian.
My recommendation is to use the 'unloaddb' tool on the production server, export the database in some directory, SCP that directory to your development server, and then use the generated 'copy.in' file to create the development database. NOTE: this is the way supported by Actian, and you may find more details on this page: http://docs.actian.com/ingres/10.0/migration-guide/1610-how-you-perform-an-upgrade-using-unloadreload . This is the preferred way of migrating databases across various platforms.
It really depends on how the database has been backed up and provided to you.
In Ingres there is a snapshot (called a checkpoint) that can be restored into a congruent environment, but that can be quite involved.
There is also output from copydb and unloaddb commands which can be reloaded into another database. Things to look out for here are a change in machine architecture or paths that may have been embedded into the scripts.
Do you know how the database was backed up?