There are a number of applications on my Mac that need Java. Some of them have to use older versions of Java. Today I found an application that required a specific version of Java to be installed on my Mac. The version of Java was 1.7.0_60-b19. Ut Oh! Yes, Ut Oh! Java prior to version 1.7.0_67 had an issue installing on Yosemite and later. These versions of Java treated Max OS X 10.10 or higher as as OS X 10.1. This caused a bug where the OS version check failed and prevented you from installing Java.
There are two ways to fix this problem that I know. The first way is to modify the /System/Library/CoreServices/SystemVersion.plist file to spoof the version of OS X to 10.9. Once modified you can then install Java. Just remember to modify it back before you restart because you will be in a world of trouble. Unfortunately this trick did not work on El Capitan. The second way is to modify the Java package. This is safer since you are not modifying system files. Here are the steps.
- Download JDK 7 Update 60 for Mac OS X
- Open the .dmg file.
- Expand the package file
pkgutil –expand “/Volumes/JDK 7 Update 60/JDK 7 Update 60.pkg” “/tmp/JDK 7 Update 60.unpkg”
- Open the Distribution file using TextEdit.
open –a TextEdit Distribution
- Find the function pm_install_check() and make sure it always returns true.
- Take the expanded package files and repackage them.
pkgutil –flatten “/tmp/JDK 7 Update 60.unpkg” “/tmp/JDK 7 Update 60.pkg”
- Install using the new package.
open “/tmp/JDK 7 Update 60.pkg”
The installer will run and skip the OS version check. You should be able to install without any problems.
This post is the first of a number of articles around docker. I intend to cover all aspects of docker which means everything from running docker locally to running docker in the cloud and everything in between.
Let’s start with “What is docker?”. Docker is a platform for build, ship, and deploy of distributed applications. It is based upon lightweight container technology originally based on Linux. Docker has two main components: Docker Engine and Docker Hub. The Docker Engine is a portable lightweight runtime and packaging tool. Docker Hub is a cloud service for sharing applications and automating workflows.
Hmmm… Get it yet? Me neither. There is a lot to docker. So don’t be upset if you don’t understand it right away. Even I don’t fully understand docker and I have been looking at this technology for months now.
Docker for me didn’t make sense until I went to Amazon’s Reinvent conference last year. At the conference, there were a number of presentations on docker that helped answer questions like “What is docker?” and “How do I get started?”, but more importantly they answered questions like “Why docker?”. New technology is great, but unless you can make it relevant to your needs then it really isn’t something interesting enough to focus on. Fortunately for me, docker was hyper relevant.
I had just gotten done a major mobile application called Peep which ran on Amazon Web Services (AWS), Amazon’s cloud platform. Peep is a real-time photo sharing application available on the Apple Store. I will highlight Peep in more detail in a future blog post. The most important thing you need to know is that Peep was originally deployed to about twelve virtual machines running on Amazon Web Services. With docker we could have reduced our footprint to about five virtual machines. That is over a 50% reduction in the number of virtual machine and over a 40% cost savings. Hmmm… Me likey! I needed to know more.
The potential for reducing your virtual machine footprint is one of many reasons to use docker. The other features that peaked my interest were deployment packaging, dependency management and portability. I saw a demo of an application packaged up in a docker image and run on completely different operating systems and infrastructure in a matter of a few seconds. With these features I could package our application and run it in development, QA, and production without any code changes using the same deployment package. Better yet, I could run our application in either AWS or Azure. With docker it doesn’t really matter much where you run your application. This capability is nirvana to a developer. Of course not all applications can do this because of dependencies on cloud providers, but if your application doesn’t have any specific dependencies, then this capability is fantastic.
Unfortunately docker was relatively new at the time [even though the technology had been available for years] and Amazon’s support for docker was in beta. Roll forward to today and Amazon now has its first release of the EC2 Container Service which is based on docker in production. Even Microsoft has announced support for docker on Azure, Microsoft’s cloud platform. So now is a perfect time to understand docker. So let’s get started!
First let’s visit the Docker home page at http://www.docker.com. Here you will find all things docker. This is where you will find the “What is docker?” video. I highly recommend that you view this video. The next step is to install docker. For our purposes we will be installing docker on a Mac using boot2docker. I will provide future blog articles that cover Windows and Linux.
boot2docker is a quick way to get docker installed and running on your Mac. It includes a tiny version of Linux called Tiny Core Linux. The reason is that docker cannot run on a Mac directly because it relies on Linux specific kernel features that are not available on OS X. The author of boot2docker chose Tiny Core Linux over CoreOS because they wanted to minimize the startup time (see Boot2Docker FAQ). That is something I greatly appreciate and hope to leverage in certain production workloads in the future.
You can download and install boot2docker by visiting their GitHub OS X Installer page. Here you will be able to download the latest release of boot2docker. At the time of this writing the latest release boot2docker v1.6.2.
Unfortunately visiting this page and installing boot2docker is not sufficient to understand how to use docker on OS X. Most of us would open up a Terminal client and start typing docker commands. That is certainly what I My first attempt I got the following error:
“FATA Post http:///var/run/docker.sock/v1.18/containers/create: dial unix /var/run/docker.sock: no such file or directory. Are you trying to connect to a TLS-enabled daemon without TLS?”
It wasn’t until I visiting the official docker page for running on Mac OS X did I realize my problem. I had to run the boot2docker from the Applications folder. This is an application that opens up a terminal window, creates an appropriate boot2docker directory, creates a virtual machine (based on Tiny Core Linux and the docker daemon) using VirtualBox, and then runs that virtual machine. Remember, you need to run docker inside a Linux operating system because it depends on Linux kernel features. More specifically, it relies on LinuX Containers (LXC) which is a kernel-level feature that has been available for years.
When you run boot2docker from the Applications folder you get a docker host that can now run docker instances. This host runs on VirtualBox and leverages the underlying hardware of your Mac. From here you can run any number of docker images that you have available. By default if you specify a docker image and it is not available locally, docker will connect to the Docker Hub to download that image and run it.
Let’s start by checking what images we have available locally. We will use the docker images command to list those images stored locally. You will see that there are no images stored locally since this is the first time we are running docker. Now we will download and run the‘hello-world’ docker image stored in the Docker Hub. For this we will use the docker run hello-world command.
Congratulations! You have now used docker to download an application, albeit a simple application, that was deployed using a docker image. There are many other commands that docker has. We invite you to do some exploring on your own by using docker –help. Next in this series we will explore Docker Hub and what docker images are available for you to use.
Some who have worked with me think I am a really good services developer because I know a lot about SOAP-based Web Services, ASP.NET, WCF, and .NET. Others think I am a web developer because I know how to build web applications using REST-based Web Services, AngularJS, jQuery, and HTML. Even more think I am a cloud developer because I know a lot about Amazon Web Services and Microsoft Azure. A few think I am a HPC (high performance computing) developer because I am an expert at using Digipede and Windows HPC Server. Friends of mine think I am a mobile developer because I write mobile apps for iOS, Android, and Windows Phone using Visual Studio, Xamarin, and XCode. And yet even others think I am a database developer because I know something about ADO.NET, Entity Framework, SQL Server/SQL Azure, PostgreSql, and more. The reality is that I don’t constrain myself to one technology, platform, or stack. I am what they call a full stack developer and architect.
However, one thing that many people don’t know about me is that I am a SQL Server Certified Master. Yes, you heard me, a SQL Server Certified Master. No, I am not a DBA. I could certainly do the work of a DBA, but that is not me. It takes a lot of effort to become a certified master in any of the Microsoft products. I had to put in 840 hours, 5 weeks straight, nights and weekends studying, taking tests, performing lab exercises, and more to achieve this status. Even then, if I didn’t have the culmination of my years of experience developing applications on SQL Server I would have not passed. For SQL Server, there are only a few hundred MCMs in the world. I feel very privileged to be a part of an elite few. Unfortunately not many know that I am a SQL MCM. Of course if you are reading this blog post, you certainly will know now.
So why this blog post?
Just this week a good friend of mine who I have known for about 8 years texted me and then pinged me on Skype. Something must have been urgent. He said, “Do you know anyone that can help with a database?” Of course I laughed when he asked me this question. I said, “Which database?” He said, “SQL Server”. Of course I laughed some more. I immediately informed him of my status as a SQL MCM to which he said, “Jeez, you do everyone.” What was interesting is that his need for a database person was something simple that was causing them great stress. It literally took me less than 30 seconds to understand the problem and tell them how to fix it. It was the familiar problem where the SQL Server user accounts in a restored database do not match the SQL Server logins on the server. A quick reference to sp_change_users_login (Transact-SQL) solved that problem. Any good SQL Server DBA would have been able to fix this in a similar amount of time.
This “Help! I need a database guy” made me realize that I needed to do a little more advertising of my capabilities, especially around SQL Server, since a friend of mine who has known me for 8 years didn’t know that I knew a great deal about databases or that I was a SQL MCM. Now you know the reason for this post.