Today I created a virtual machine for mongoDB. It’s a long time since I worked last time with it. So I wanted a generic machine that I can start, stop or destroy without the need to reinstall it everytime by hand. Sounds like vagrant and ansible 😉
Get our hands dirty
As mentioned, I will use a Vagrant base image of Ubuntu 14.04 and provision it with ansible to install and configure mongoDB. Since I don’t like to use vagrant portmapping for all port that I may be using, I like to use the vagrant plugin ‘vagrant-hostsupdater’.
- Install vagrant from here.
For example on debian or ubuntu:
1sudo dpkg -i ~/Downloads/vagrant*.deb
- Install vagrants hostsupdater plugin:
1vagrant plugin install vagrant-hostsupdater
- Install git and ansible on your machine
1sudo apt-get install ansible git
- Clone my git repository and change to the directory:
1git clone firstname.lastname@example.org:hauckd/vagrant-ansible-mongodb.git && cd vagrant-ansible-mongodb
- Just run the vagrant machine
- That’s it!
After the startup and the provisioning of the vagrant machine finished you either can ssh into the vagrant machine to play with your mongodb instance
or connect directly to mongodb with
That’s the cool thing about the hostsupdater plugin, you can interact with the machine just like a real host, just give it a hostname in the Vagrantfile.
So after a couple of minutes you are up and running and can begin your journey with a great noSQL database management system.
Don’t forget to follow me on twitter or subscribe to the newsletter on the left site to recieve the latest posts. Of course you can give me a few stars on github 🙂
Grüß Gott and a nice evening!
Today I am going to talk about this thing, everybody heard about, it’s ‘DEVOPS’. No, I’ll not. At least a bit.
Devops means a melt between the developers and the ops guys. We should use the same processes, tools and stuff.
In my honest opinion, the developers do the ‘melt’ better than us(the evil ops). They automate their minification and unit tests and all these helpful things. The learned their lessons.
But we(the ops) often miss to learn from them. How often I see creepy(really creepy) server configs, no matter if apache, nginx, icinga, ansible, whatever. Why the most of us don’t stick to some kind of coding standard? Why the f… we don’t use CI tools like the devs do? Why don’t we use lint-tools like devs do?
It ain’t that hard to define a standard about using tabs or spaces in your icinga config.
It ain’t that hard to define a vim command that lints your ansible config BEFORE writing.
It ain’t that hard to configure your CI-server(i.e. jenkins) to clone your icinga-repo and do a simple config test before syncing it to production.
It’s not just about checking the config for errors, it is also about collaboration. I hate it, when someone asks me to take a look at his config file, why it’s not working and I recognize 30 different indentation styles or lines about 300 chars. It will take at least the double amount of time to find the small little error, the missed semicolon or similar, only because of a bad style. I have to cite PanadeEdu on twitter, he puts it in a nutshell:
Standards have nothing to do with preference. They have to do with collaboration. #becauseReasons
— Florian Tatzel (@PanadeEdu) 9. Oktober 2015
So what’s the point? We have to do our homework too!
In the next few posts, I’ll bring some topics that will help you achieving this goal.
– Code Quality for Sysadmins, Operations
– CI/CD for Sysadmins, Operation
– And many more!
As always, subscribe, follow me on twitter to receive the latest posts!