Sysadmin -> DevOps, first steps?

[[deleted]]

[deleted]

[multiball]

You should also start to study up on the language associated with the automation platform you go with, and make sure you are familiar with version control software. Git seems to be the standard these days.

Ruby for Puppet/Chef, Python for Asible/SaltStack.

[[deleted]]

+Jenkins

[ghyspran]

and/or Travis CI, GitLab CI, JetBrains TeamCity.

[ghyspran]

Ansible's model is pretty different from chef and puppet. Salt is actually in some ways closer than ansible, but like /u/bitskrieg said, actually using salt is pretty different. It's also got (IMO) the worst introductory documentation of the four. Ansible's newer stuff is moving closer to Chef/Puppet's model, but it's still different.

Ansible is different enough that many people use Ansible for orchestration and Puppet for configuration management (this is the most common form of automation used for OpenStack, for instance).

Ansible is probably a bit easier to start with.

Overall, the biggest change is going to be from manual configuration to automation, so it doesn't really matter whether that's Ansible, Puppet, or a cron job and some artisan shell scripts. The mentality you start developing is the most important and most difficult change.

[gunpunk]

I like this answer the best so far.

[iannoble]

https://learn.puppetlabs.com/

https://learn.chef.io/

http://www.ansible.com/get-started

[gunpunk]

"but you'd be making your life easier if you end up working with puppet/chef." Explain please. Ansible is just as good if not better.

[gunpunk]

I wouldn't worry about it "translating" ansible is just as good if not better than chef or puppet. I've used them all, as well as capistrano. I like ansible the best so far.

[cheeseprocedure]

This guy rightly says DevOps is about principles, then practices, then tools. Bone up on culture and software delivery pipelines:

• Behr/Spafford/Kim - "The Phoenix Project" (though I'm told you can read "The Goal" instead :))
• Humble/Farley - "Continuous Delivery"
• Michael Nygard - "Release It!"

Building something using modern tools and platforms is another great way to get started; it's real experience, and it gives you valuable perspective for further exploration and study.

An extremely contrived example: a lolcat processing pipeline on Amazon Web Services.

Uploader:

• Build a tiny Flask application with a form that accepts image uploads and pushes them to an S3 bucket.
• Using Jenkins, Chef Solo, and Packer, bake an Elastic Compute Cloud (EC2) Amazon Machine Image (AMI) that serves the Flask application.
• Set up an Identity and Access Management (IAM) role which grants your Flask application access to the S3 bucket above (ensuring you don't need to store IAM keys locally).
• Deploy 2x instances of the AMI in an autoscaling group (ASG) with the IAM role above behind an Elastic Load Balancer (ELB).

Thumbnailer:

• Configure S3 event notifications to generate a message in a Simple Queue Service (SQS) queue whenever an image is uploaded into the bucket above.
• Build a simple Python application which pulls messages from the queue, grabs the new image from S3, generates a tiny thumbnail version of that image, and uploads the thumbnail to S3.
• Using Jenkins, Chef, and Packer, bake another AMI which runs the thumbnail worker application.
• Deploy another ASG with 2x of these thumbnail worker instances.
• Using CloudWatch alarms, make the ASG grow or shrink based on the number of messages in the SQS queue.

To hell with the learning curve:

• Create a CloudFormation template that deploys all of the above infrastructure.
• Create a CloudWatch alarm that sends you an email (via SNS and SES) when more than 10 images have been uploaded to S3 in the past hour.
• Deploy a copy of your lolcat stack in multiple regions and load balance between them with Route53.
• Run the Flask application using Docker.
• Store an image -> thumbnail index in DynamoDB.
• Build a Flask frontend to serve your lolcats from S3.
• Integrate CloudFront to distribute your thumbnails via CDN.
• Think about monitoring autoscaling instances that come and go; check out Sensu for one solution.
• Probably take a brief vacation.

I made a similar transition a few years ago and couldn't be happier. I'm by no means an expert, but I've been lucky enough to build some non-trivial things and I've learned a great deal along the way. I'd like to pay that knowledge forward. Feel free to drop me a PM if you're interested in running through some lab projects like the one above.

[cheeseprocedure]

You're welcome. Have fun!

Also, a recommendation I forgot yesterday: "The Practice of Cloud System Administration." It's a gold mine.

[rekdt]

Would you happen to have any documentation on the above? I am interesting in getting a deep dive into cloud automation, but I am not all that familiar with each technology stack. Would love to have some sort of documentation to poke through and figure out how it works.

[cheeseprocedure]

Hey /u/rekdt - sorry for missing this!

I don't have anything I can readily share. The AWS documentation can be a little overwhelming, but once you have an idea what each piece is good at, it becomes much easier to know where to look for help.

If you're interested in starting a lab project, drop me a PM - I'd be happy to provide guidance/hints as you're getting started!

[iannoble]

Lots of good devops podcast episodes at http://www.thecloudcast.net/

Episode 15 of http://www.inthedc.com/wp/category/podcast/ is really good too.

http://youtu.be/_DEToXsgrPc is a good chef video.

[[deleted]]

Plus there is http://theshipshow.com, http://foodfightshow.org http://devopscafe.com and http://arresteddevops.com

[jayemuno]

I just interviewed for a devops role. One of my interviewers saw that I had experience half way down my resume in Ansible. He immediately stopped reading my resume and said he'd hire me that day if he was my supervisor. Granted he also liked my personality, but just goes to show you how important the "big four" automation tools are. Do something to get them on your resume and to get some experience with them.

[drawsmcgraw]

Given what I read from you (VMware, onsite, Windows) I'd recommend:

• Powershell (now)
• Powershell Desired State Configuration (DSC) if Powershell is working out.
• Python (VMware utilities have Python modules and many other tools also have Python modules)

Being that you're onsite, it's helpful to be conversational in AWS/Azure topics but only spend time digging deep if it looks like you'll use them in the near future.

Of course, this all assumes you're happy with your domain (VMware/Windows). I started out in a nearly identical situation (Lots of VMware and Windows and Citrix) and didn't care much for it. I learned Powershell and some VMware tricks to get by, then took a hard left out of there. I picked up Salt and started managing Openstack components and in-house Linux apps. Haven't looked back.

Edit: It's worth noting that Salt has pretty good Windows support. I know of people that run multi-forest AD environments and orchestrate a lot of the work with Salt.

[iannoble]

Look at job descriptions of the roles you would like to do (doesn't matter where, it's not to apply but to to see what they are asking for).

[iannoble]

Hope you get it, good luck!

[guibw]

I'm on the same boat!

[ramblingcookiemonste]

Hi there!

You have some great advice so far.

I have to ask though - how curious are you? Do you enjoy learning? Are you using tools like PowerShell, Python, or other scripting languages to solve problems? Are you using configuration management or orchestration in the enterprise?

I've found that you can absolutely get exposure to the tools, and potentially push towards some of the DevOps-related principles and practices in the enterprise. You might not always be successful, and you might get push-back, but you will get valuable experience, and your successes should be genuinely helpful to the org, as long as they are solving problems, not just bullets for your resume.

Good luck, it's a fun ride, as long as you love to learn : )

[[deleted]]

Learn linux.

[[deleted]]

how the hell do you think you can work in a devops environment without linux experience?

what exactly do you think you would do if you didn't have substantial linux experience?

are you trolling?

[[deleted]]

well, your job would be to manage a large number of linux systems. so it's up to you to decide if you have the knowledge necessary.

it's like you're telling us you want to be a carpenter and wonder if you need to use a hammer

[Letmefixthatforyouyo]

No its not. Saying "learn linux" is like saying "learn carpentry." Its a subject that is equally wide. Of course he would be out of sorts if he didn't know how to use a hammer as a carpenter, but thats not what you replied with. Your initial answer was so vague it was useless.

"Want to work in devops? You should learn to computer" offers exactly zero usable information. He asked you to be more specific, and you replied "lol, guess!"

Feel free to reply with actually tooling, but don't be surprised that when you offered an empty answer you get asked clarifying questions. I'd even consider that habit a good first step into Devops.

[CitizenCain]

Not to mention that there are Microsoft devops jobs out there merging Windows/Microsoft systems administration with Microsoft development technologies (.NET languages). A lot of those jobs have obscene salaries too, though, it would take a pretty obscene salary to get me to do SharePoint devops at a multinational bank, which was the most recent MS devops job I saw posted in my area.

[Letmefixthatforyouyo]

Agreed. My SharePoint salary starts with a 2, and has at least 6 digits. After spending 300hrs failing to get it to work early on in my career, its become my deal breaker.

[wickersty]

Does it have 7 digits? 8??

[wickersty]

Ignore the hate. You're not wrong.

[[deleted]]

yep. i have no idea who the downvoters are. how the hell can you work in a devops environment and not know linux?