DevOps | The 360° Provisioning of a (Mongo) Database

Provision vs Install

Auto provisioning a (Mongo) database end to end is not easy – many confuse installing and provisioning – one is just a small part of the other.

Provisioning a database twists and turns like a snake on an obstacle course. DevOps (SRE) engineers are worth their weight in gold due to the number of technologies and angles involved in a provisioning use case.

This paper covers provisioning a secure real-world Mongo database for a Java Application using Ruby, Vagrant, JavaScript, Git and Amazon S3.

Begin At The End | The 360° Observable Value

Auto provisioning MongoDb (indeed any database) requires us to tell the app (micro-service) where the database service is and the credentials to be used. It requires security – so the credentials are short lived.

So beginning at the end, what 360° observable value must be delivered.

  • the entire provisioning use case is overseen (using Ruby)
  • a vm is created and MongoDb installed (using Vagrant/VirtualBox)
  • user credentials are registered with the MongoDb (using JavaScript)
  • application data is restored into the MongoDb instance
  • secure MongoDb only allows connections from the app’s IP address
  • secure the usernames and passwords are generated
  • the IP Address, Port, Db Name and User Credentials are placed in a file
  • the JAVA application is informed using a Spring Data XML configuration
  • a URL (that expires) to the MongoDb XML config is placed in app.properties
  • the app.properties is placed off the home directory of the application

Leave a Reply

Your email address will not be published. Required fields are marked *