As I have received multiple requests now, I decided to make a little bonus for you 😉
It seems like a lot of you preferring MySQL over PostgreSQL. I don’t understand why, but that’s another topic 😉
Hurray! This is for now the last part of this tutorial series. Today we will install symfony. Or better said, we will install the symfony installer.
What would be a modern web application without a database? Ok, you could also build an API that just takes data modifies it and give it back to you. Or a static site generator or whatever. But in most cases, you will build apps with databases.
Oh man, this is hard, we are at part 4 and haven’t seen anything. This sucks. Let’s change it!
In this tutorial I will show you, how to install nginx and add virtual hosts, of course provisioned 😉
In this part of the tutorial I will show you, how to use the raw module of ansible. This will be a shorter one, in which we will just install composer.
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!
Lazy dude? Listen to the audio version!
Don’t get me wrong, I love automation, I automated a lot of setups and configurations in the past, including:
- The setup of hundreds of servers
- software deployments
- the installation and maintenance of my notebooks, desktops and raspberry pis for home control
I started my career without any of these tools, like ansible, puppet or stuff. We used bash and python scripts to automate routines that appear everyday…
What’s the problem with automation?
Like I told, we dont’ worked with these tools from the beginning, so we did a lot of the things by hand first, without just hitting ‘ansible do-all-the-stuff’. It took longer, sure. But after setting up the services ourselves, we know how every piece of the system works. And the more important thing, we know how to fix the system. I am not saying you shouldn’t automate, automation is great. But I met lot of people who rely on their automation system, to do all the stuff for them. They don’t know how to search for errors or fix them, because they don’t know how to setup the system without configuration management tools. If you setup a service by hand, then you got the knowledge how to tweak the configuration and you get a better understanding and feeling for the service. You’re not looking at top or ps, ander wonder why three processes are running for dovecot. You know why the service is running, because you configured it, not ansible, not puppet.
So, what should I do?
You should automate all the things! No, nothing is wrong with me, I am not schizophrenic. But before you automate the deployment, the installation or whatever, make sure you did it once per hand. Then you got the knowledge and the feeling, how the service works and why it works like that. If you have to setup a 100 node mail or database cluster, with sharding or other crazy stuff, you’ll be glad if you know it works in the background.
What do you think? Drop me some lines in the comments!
Thanks for reading and be sure to follow me on twitter or similar! Have FUN!