- [Instructor] Okay, welcome back. In this lecture, I'll demonstrate how to compile and package the API into a lightweight, deployable micro service, using Docker. 

Starting off in the Demo directory, I'll clone the API repository into it like so. I'll then navigate into the new vote-app API Go directory, and list its contents. Let's now take a closer look at both the go.mod and the go.sun files. These files declare all of the third party packages that the API depends on. To be able to perform a Go compilation, we first need to download a local copy of these. Let's clear the terminal and now run the following Go get command to download all of the required dependencies. Go, get, dash v for verbose. 

Excellent, Go has downloaded and installed our dependencies, but, exactly where? Let's go and find them. I'll next run the command go env for environment to display all of the Go environment variables, like so. The Go path, which is now highlighted is where we need to go and take a look at. We can do so by running the following command: cd, opening back tick, go, env, GOPATH, closing back tick. If we query the current directory path, we can see that we have indeed been swapped in to the directory tracked by the go path variable.

If we now list the contents of the current directory, we can see the standard Go directories, bin, package and source. If we then navigate into the package modules directory, like so, then we'll start to see where our downloaded dependencies have been saved to. Okay, I'll now jump back into the API project group directory, like so. Right, we're now ready to compile our API. Before we do, I'll display the contents of the current directory. Notice the absence of an API file. Let's now create this file by performing a Go compilation, over our source code. I'll run the command, Go Build, dash O for output, API, which is the name of the Binary. Now that was quick, this is one of the benefits of Go. Quick compilation. If we relist out the contents of the current directory, we can now see the new API binary created by the previous command. This API binary has been compiled for the current operating system. Therefore, it should be executable. Let's try it. I'll clear the terminal and then execute the API like so. 

As you can see, the API has launched fine, and is now attempting to connect to the backend mongo DB database. Using the default connection string, which is not valid for our local environment, we're not worried about this now. Let's kill the API process and move on. Since we're going to be running the API binary with an A container, we actually need to recompile it for the Linux operating system that the container will be based on. Therefore, we need to recompile it explicitly for the Linux operating system, like so. This instructs the compiler to create a binary that will be executable on Linux running on an AMD 64 Architecture. 

Okay, again the compilation has been successful, and the API executable has now been recreated. This time if we try to run it locally, it will fail, since my Mac doesn't understand the binary format. At this stage, we are ready to build the API docker image. Let's again clear the terminal and then display the contents of the docker file located in the project route, like so. What should stick out about this docker file, as with the previous docker file, is its simplicity. We are deriving from the alpine image, a very compact Linux based operating system. We then copy across, the single API binary, and run it up, exposing it on port 8080. Okay, now for the magic. Let's build and tag the API docker image like so. Again, if we examine the local docker images, we now see the new version one API docker image, another great result. 

This completes the build and packaging phase for the API micro service component and has put us in good shape to progress to achieving our end-to-end cloud in aid of application, running locally.