If you ask a group of people "what is DevOps?" you are likely going to get a variety of different answers. Some think it's just the automation of a pipeline. Some people may say it's just developers doing operations work. I subscribe to the idea that DevOps is a mental model for how to think about creating software. So with that, let's take a look at the core principles behind DevOps.
I have been developing Ruby on Rails apps in Docker for several years now. I couldn't imagine not using Docker for serving my projects at this point! See how I build docker images meant to be run in production for my Ruby on Rails projects.
Here is a directory structure that I am using for Terraform that I think works pretty well. The quick and dirty of it is to think of your configurations in terms of a organizational and systems hierarchy, and to design your plans to support that hierarchy. Each tier depends on and builds upon the previous tier.
Ruby on Rails is quickly becoming my framework of choice for my personal websites and projects. It's a pleasure to work with and has been easy to learn. But no framework is without its challenges. One of those challenges is of course deploying the app to a server. There are a lot of options for hosting and deploying a Rails app. But, I like to run my own servers which means I have to also take care of deploying to those servers. I'd prefer to be deploying images to AWS ECS but I don't need that kind of infrastructure for my personal website. It's just a blog it can suffer seconds of downtime when I deploy updates. So my approach these days is to use Ansible to handle the deploy steps.
My first year at Blackbird has been good. My main goal in my first year was to migrate the monolithic system and infrastructure into something more scalable and reliable. Well this week was the week and we did it. We moved the last of the services over without any issue. I am grateful that I had the support I did and the team I did. I have learned an incredible amount from them. And ultimately, we killed it!
You want to share a topic branch with a colleague but do not want to push that branch upstream to Github/BitBucket/GitLab, etc. How do you do this? You could create a patch and email it. Or you could do it in the most crazy way possible and use Apache and allow your colleague to pull from your repo directly. This does take a bit more time to setup, but it would also be absolutely crazy dumb for everyone involved. Basically, let's setup a git server on your workstation!
Here is a rough outline of my Pantheon + Jenkins process. I like my code in BitBucket. I also like Pantheon (check them out). The Pantheon workflow is all about being the source of truth for your code. This is fine, and actually I dig it because it promotes good practices. However, I, and my company, have many projects in BitBucket already, and am using Jenkins more and more for some Continuous Integration functions. We want to keep using BitBucket as our source of truth and our existing workflows, but also want to use Pantheon.
This is the Vagrantfile I am using for my development box at home and work. It is determines how much ram is available and how I want to allocate, how many CPUs are available, and configures the VM for me. I use NFS for shared folders. Finally, starting to use "hostupdater" to keep my host machines hosts file current.
Media Temple uses the OpenVZ virtualization system and I have quite a few Media Temple servers under Chef management. The one thing that has made management difficult is that by default during a Chef run ohai returns 127.0.0.1 as the default IP address which means I cannot run knife to execute commands from my workstation.
I use Chef to manage and provision new staging and production servers in our company. It takes a lot of the headache out of managing multiple servers and allows me to fire up new web & data servers for our projects with ease. I have several cookbooks that I use to configure servers and to setup/configure websites. In a nutshell, it's rad, and website deployments have never been easier.
It was brought to my attention at the office that a few of our recently launched websites had publicly exposed .git repository information. Unscrupulous users could use the exposed data to pull down the entire commit history, giving them unfiltered access to what is basically the blueprint for the website.