Does the GO program need Docker?

This is a creation in Article, where the information may have evolved or changed.

I'm a fan of go and I'm also interested in containers. Containers can make code easier to deploy and easier to scale. But not all go programmers use containers. In this article, I'll explore some of the reasons why you should really consider using go and containers-and then we'll look at some containers that don't add any benefits at all.

First, we want to make sure that we are all at the same starting point.

What is a container

For those who use these containers, there may be many different definitions. For many people, the word "container" is synonymous with Docker, although containers are much older than Docker open source projects or Docker companies. If you are a new user of the container, Docker may be your best starting point for developer-friendly command-line support, but there are other implementations available:

• Linux containers-container implementations, including LXC and LXD

• Rkt-pod-native container engine from CoreOS

• Runc-running containers by OCI specification

• Windows containers-Windows Server containers and Hyper-V containers

Containers are a virtualization technology-they allow you to isolate your application so that it sees itself running in a separate physical machine. In this sense, a container is similar to a virtual machine, except that it uses the host operating system instead of having its own operating system.

You can start a container from a container image, which bundles all the content that the application needs to run, including all of its run-time dependencies. These mirrors make it easier to distribute the program.

Containers make it easier to distribute your code

Because a dependency is part of a container image, you get exactly the same dependencies when you run it in a dev, test, or production environment. Problems that result from the environment differences between the data center machines and your notebooks will no longer exist.

But one of the advantages of go is that it will be compiled into a single binary executable. You must handle dependencies at build time, without run-time dependencies, and without the need to manage libraries. If you have ever worked in Python,javascript,ruby or Java, you will find that this feature of GO is its advantage: you can get a single executable file in the Go compilation process, which can run on the machine you need. You do not need to ensure that the target machine has the correct version library or execution environment.

Well, so, if you have a binary file, what's the point of packaging the binaries in the container?

> The answer is maybe there's something else you want to pack in your binary. If you are building a Web site, or if your program comes with a configuration file, you might separate the static files. You can use Go-bindata or a similar method to build them into an executable file. Or you can use a container image that contains a binary file and its static resources. No matter how you place the container image, it has everything you need to run the program.

container to help you deploy your code

Let's assume you don't have any static resources, just a binary file. You build the executable file, and then move it to the computer that you want to run (you only need to move the file). Go makes cross-compiling easy, so it's no big deal even if the target machine to run the code is different from the code you're building. All you need to do is specify the architecture and operating system of the target machine when you run the go build.

In many traditional deployments, you will know exactly which executable file the (virtual) machine will run. You might have multiple hosts (for example, for high availability), but now we know it's easy to build containers for the target machine, and deploying the go binaries to the machine is not an enigmatic thing.

But the modern way to deploy is to run a set of machines and place the containers somewhere in the cluster using coordinators such as Kubernetes,ecs or Docker swarm.

Containers are useful for this because mirroring performs the standard "deployment Unit" as a coordination. The administrator tells the machine what code to run by giving it an identifier for the container image. If the machine does not yet have a copy of the image, it can get it from the container registry.

Of course, you can also run a process to deploy code that is not packaged in a container image. But by using containers, you are leveraging a widely used and language-neutral deployment approach that is increasingly being used in the industry. Even if your company is a pure go language stack today, by using containers, you will have a common mechanism for deploying different code components. Regardless of which language they may use, avoid language locking.

When I say "modern ways to deploy code," you might well think of a "no Server" architecture? A server-free architecture is the execution of an executable function within a container. Deploying to a server today looks a lot different (compared to other ways), but I'm not surprised to see these terms-in some environments, you can deploy a service-free function in the form of Docker container mirroring (not just that it has full dependencies).

Container restricts the resources that code can access

When you run go (or any other) executable on a Linux machine, you start a process. If you execute code in a Linux container, you will start a process almost exactly the same way. The process actually thinks it runs on a separate machine and has all the resource permissions.

You can restrict program permissions within a container. Virtual machines have many of the same benefits of running multiple different applications on the same hardware. For example, a containerized process cannot access a file or device outside its container, unless you explicitly allow it to be accessed, so it cannot affect these files or devices (due to errors, etc.). It may be assumed that all CPUs can be used for CPU-intensive operations, but the system may limit its ability to use the CPU so that other applications and services can continue to run.

Resource limits are created by using namespaces and Cgroups. These terms mean what is the subject of another era, but people tell me that they find it helpful to see the speech I made in England.

If you want to restrict executables and access only a limited set of resources, the container provides you with a neat, friendly, and repeatable way to do it.

You can create the same restrictions for executables in other ways, but it's easier to use containers. For example, traditional system administrators have done a lot of work to set permissions for files, devices, and network ports. In the world of containers, developers can easily express their intention that the code should be able to use certain ports or volumes (not other ports), and by default, everything inside the container is private to the container. You need to ensure that your dockerfiles follows the best security practices, and each time a development team deploys a new application or service, no custom actions are required to get permission settings.

Containers to help you test other components locally

Many applications require access to other components, such as databases or queued services (or other infinite). You will also need to install these components when you want to run the program locally for testing.

But what if different applications need different versions of the components? Or if the configuration of different projects differs? For example, if you are a developer, you can easily run two clients with different versions (for example, Postgres). You can run multiple copies on your laptop, but it can be painful (you must make sure that you use the correct version).

If you use the Docker version of the service you need, life can be much simpler. You can set up a docker-compose file for each project to start the correct set of components with the correct configuration.

What the container can do for you

In short, Docker is easy:

• Distributing code to packages that can run anywhere

• Deploy your software with a facilitator

• Restrict the resources that you (or someone else's) code can use on the host

• Run and test your software locally (including all required services)

If you're a go developer working on "back-end" development or system software that deploys code to the cloud, these are the reasons why you might use a container. But if those are not for you, should you make Docker deploy go code?

when the container should not be used

Docker has a slogan: "Build, ship and Run any App, Anywhere." Go already has some built-in properties to support this. As I mentioned earlier, such as cross-compiling and generating a single executable file that is not dependent. Unless you use an executable file to package other files (or new plugins), the container does not provide convenience unless "run" means "deploy through the orchestration."

Maybe you're a go developer, and you don't have to worry about deploying your code on a set of machines. If you create a standalone desktop or mobile application as a download distribution singularity, then using a container will not add any benefit, but will increase the unnecessary complexity of your workflow and build process.

Similarly, if I'm writing a standalone program (I'm just going to run it locally, maybe an experiment or a demo, or a small utility that doesn't need to interact with other components), I won't use the container. As always, use the right tool job and don't use the container if it doesn't add value.

Are there other reasons for using containers? I'd love to hear your story.