Debugging Is Easier With Docker For Mac

Docker is gaining traction in the software development industry at such a phenomenal rate that more and more teams are adopting it into their processes. Keeping everyone on the same page with technology stacks has become increasingly difficult as the technology itself becomes more complex. There are countless technical articles on Medium extolling the virtues of Docker and how it can help mitigate these types of problems.

Now that I have been using Docker as a local development environment for over a year, I’d like to talk about the pros and cons of making the switch. Pros Docker on Mac and Windows are better than ever.

Docker is getting more and more mature by the day, especially as more developers are turning to it for the development and production environments. Docker for Mac and Docker for Windows reduces much of the complexity of leveraging Docker on non-Linux environments through abstraction. It now works as simply as any other application in your environment - install it in the same fashion as your other tools like your text editor and browser - and you are off to the races. Docker gives you consistency across your team.

Another aspect of Docker that I love is the reliability that you have the same setup as your team. This is great for a couple reasons: there is so much value in being able to run with the assumption that your entire team is using the same setup, and it enables you to run scripts and processes that will empower your entire development team to perform common operations with a simple command. Docker eases the pain of debugging environments. Our processes used to consist of having to track down pages and pages of documentation, only to find that this documentation is out of date and needs to be updated, so where do I end up? Spending days pouring over posts on Stack Overflow trying to find out how to update the services I’ve been using on my machine, which are probably different than everyone else’s on my team. So each developer needs to do that exploration independently because each solution will be slightly different.

With Docker, you can easily isolate and eliminate environment issues across your team without needing to know how someone’s machine is setup. Interesting avenues of automation open up with Docker. As someone who is fascinated with automation, I’ve always tried to find shortcuts to doing the boring, repetitive jobs that take too much time to do manually. Have to update the database on the development server? Ok, great, you just need to look up the password for the development server (which could be any of 4 different places, depending on the project) and once that’s done, you realize you also don’t have the password for the live or staging environment, so you have to wait 3 days for the call from the IT firm that manages that server to give you credentials.

With a Docker infrastructure, you can easily transfer the environment (with some small utility changes) to the CI system of choice. Most of the prominent CI solutions available today integrate well with Docker. Docker speeds up the provisioning process. You can avoid wild goose chases by providing all you need from within the docker container, potentially using a set of shared ssh keys, or requiring users to use personal keys on an identity service (best case scenario, but impractical for some teams). Docker for Mac and Windows is more stable than ever before. Even with its rapid development cycle, the team working on Docker for Mac have done an exceptional job keeping the platform as stable as possible.

This is important because the app auto-updates. Despite the fact that I am on the Edge version of the platform (which seems to update weekly), I have only had one issue that caused me to have to rollback. I ended up losing a day of development time to this bug, but after I found a way to rollback gracefully, the following day there was a bugfix released to remedy the issue. Despite this one small glitch, I still stand by Docker because I had more conflicts when I was relying on Homebrew or compiling binaries for services manually. The Docker community is huge and resources are plentiful. There are a huge number of images (last count on Docker Hub has it at 100,000+) to pull from for free from Docker Hub. These images are blueprints to creating your containers which will house all of your services for your application.

You will find varying success on the level of documentation each of these images provide, but for the most part they are ready to plug into your application. Cons Despite all of these good things, everything is not sunshine and rainbows with Docker, though. There are many things about Docker that can be tricky to grok with and it helps to have someone on your team familiar with the technology. Docker has some gaps in documentation. Docker is moving at a fast pace and it is very hard to keep up with the latest advances and changes. While there is some fantastic documentation, there seem to be some gaps specifically within the docs for the abstraction layers (Docker for Mac, Docker for Windows). Docker has performance problems on non-native environments.

Despite Mac being based on the native Unix layer, Docker still requires the actual Linux kernel (usually Ubuntu) in order to perform its operations. What Docker for Mac provides for you is an abstracted VM containing the kernel, which you never interact with directly.

Debug Is Easier With Docker For Mac

You will interact with the containers within that VM, but they are networked together with your host in a way that you will rarely need any information about the VM itself. Using Docker (or any VM-based architecture) locally has one drawback which can be significant based on your stack and your team’s needs. The disk mounting / volume shares Docker for Mac provides are getting better with every release, but I have seen some pretty substantial drop offs of performance when doing intensive database operations. Docker for Mac performance: A Test Case My test case was using Docker for Mac and installing a web application framework (in my case, Drupal). On natively-compiled services (ie Homebrew), I could install Drupal in 45 seconds.

Originally, with settings out of the box, Docker for Mac clocked in at 20 minutes and 32 seconds. I knew this couldn’t be reality, so I ended up twisting some knobs and flipping some switches (probably worth a follow-up article at some point) and got it down to 6 minutes, 47 seconds. While this is a significant improvement over the factory settings, it still leaves a lot to be desired in terms of performance. There can be a significant learning curve to migrating to Docker. Learning Docker is a significant time sink.

There are a lot of concepts that are just different enough from a Virtual Machine infrastructure to cause confusion and make unlearning concepts from other areas a bit more of a challenge, even for experienced developers. Is Docker right for me? Identify your pain points. Determining whether Docker is right for you is really up to your team. If you find yourself using a fairly reliable stack and on consistent development platforms, perhaps Docker is an unnecessary abstraction to add to your team’s workflow. However, if your team struggles with developer support on a platform level, Docker just might be the thing that makes the difference.

Docker can involve a large paradigm shift on a team. Having a Mac on a local, sandboxed workstation can be beneficial— and many development teams stop here. However, should your use case and expertise on the team allow for it, it is also possible to have Docker as a deployment target on your servers. You will find this best suited for when you have supporting architecture to aid in your CI/CD processes.

As expected, most of these components require a specific level of expertise. If you have an infrastructure based on VMs or even bare metal, this approach will come with a significant effort to build up the stack and train the developers/DevOps on how to use it. Reliable, but at a cost. Ultimately, I find Docker to be extremely reliable and use it in my projects which require cross-platform support. In many open source projects, for example, it is great to meet people where they are at and allow them to bring whatever they have access to. Docker can be extremely beneficial in this cases.

Let us know how you are using Docker. Please reach out and let us know how Docker has been working for your team and leave a short pros/cons list of your own for the edification of others! (Whale image courtesy of Max Pixel).