Live data from Hacker News

Containerize Go and SQLite with Docker

awstip.com

41–50 of 90 posts

Re: Containerize Go and SQLite with Docker

#41
post #34
post #23

If you are using Go (which solves most of your dependency problems) and SQLite (which means you don't need to integrate with an external database via service discovery) why do you need Docker at all?

In a production environment one would probably deploy using something like Fargate, Kubernetes or Fly.io.

> In a production environment one would probably deploy using something like Fargate, Kubernetes or Fly.io.

Docker swarm mode is pretty good and terribly easy to get up and running in no time.

I have a few small personal projects hosted on Herzner on a couple of Docker swarm mode deployments with 100% uptime in the past two years, and all it took to get that infra up and running is installing Docker on a bare Linux node.

The only downside I'm aware is that inter-node traffic speeds can be relatively low.

Re: Containerize Go and SQLite with Docker

#42
post #23

If you are using Go (which solves most of your dependency problems) and SQLite (which means you don't need to integrate with an external database via service discovery) why do you need Docker at all?

Perhaps because Docker has great stories for deployment. Many of the complexities of deployment are handled for you (writing a systemd unit, managing rollback, etc).

Yeah, but for Docker to handle the complexities of deployment, you first need to handle the complexities of Docker. So OP's question is valid: for most Go apps, all you have to do is compile a binary and copy it to the server - no Docker or other paraphernalia required. Of course that may not be so simple due to various reasons, but it helps to keep that possibility in mind...

Re: Containerize Go and SQLite with Docker

#43
post #23

If you are using Go (which solves most of your dependency problems) and SQLite (which means you don't need to integrate with an external database via service discovery) why do you need Docker at all?

They probably have 100 other apps and deploying this one without docker would make it a snowflake.

Re: Containerize Go and SQLite with Docker

#44
post #5
post #2

Add -ldflags '-s -w' to go build to strip DWARF, symbol table and debug info. See also: -trimpath

And if you can spare an extra ~150ms startup time: https://blog.filippo.io/shrink-your-go-binaries-with-this-on...

I totally understand removing annotations in the DWARF tables since they're not really needed in a production environment, but why would you want to remove stack traces? They provide invaluable information in a production system, and removing them increases the start up time with negligible difference.

In reality you'll tell whatever deployment system to deploy your binary/container, and you'll just wait until it's done. In such cases, 150ms won't make a difference in the grand scheme of things due to other systems such as your CI and other things in your pipeline.

Re: Containerize Go and SQLite with Docker

#45
post #37
post #29

Earlier quoted context omitted.

Ease of deployment?

Seems more difficult. Without Docker I don't have to bother with a new technology, use new commands and learn new syntax.

That is true, learning Docker to just do this would be wasteful.

However, many people already know how to use Docker and have flows around it so it makes sense for them to do this.

Re: Containerize Go and SQLite with Docker

#46
post #33
post #23

If you are using Go (which solves most of your dependency problems) and SQLite (which means you don't need to integrate with an external database via service discovery) why do you need Docker at all?

It looks great on CV.

And now he can add front page of HN

Re: Containerize Go and SQLite with Docker

#47
post #42

Earlier quoted context omitted.

Perhaps because Docker has great stories for deployment. Many of the complexities of deployment are handled for you (writing a systemd unit, managing rollback, etc).

Yeah, but for Docker to handle the complexities of deployment, you first need to handle the complexities of Docker. So OP's question is valid: for most Go apps, all you have to do is compile a binary and copy it to the server - no Docker or other paraphernalia required. Of course that may not be so simple due to various reasons, but it helps to keep that possibility in mind...

> you first need to handle the complexities of Docker

The complexity of Docker is not that big for a Go deployment though, especially if you have all the other bits for orchestrating your Docker containers (for the rest of your stack) already in place. You mostly just copy the binary into a slim image and you are done.

Re: Containerize Go and SQLite with Docker

#48
post #30

Earlier quoted context omitted.

I would say most of my Go projects involve what you described (logs to stdout, simple interface) but I often find myself needing a shell to debug my docker build, like ensuring that files have ended up in the correct place, and have the correct contents, within the docker container.

Use Dive for inspecting the image https://github.com/wagoodman/dive&ved=2ahUKEwips5OH0Lr1AhW97...

Your link is busted, https://github.com/wagoodman/dive

Re: Containerize Go and SQLite with Docker

#49
post #23

If you are using Go (which solves most of your dependency problems) and SQLite (which means you don't need to integrate with an external database via service discovery) why do you need Docker at all?

I deploy my app (c# with sqlite, some native dependencies) using custom-made scripts to ubuntu, centos and redhat dedicated servers and it's a major pain to have a separate script for each version of each OS. I'll switch to docker soon so that I have a single target

Re: Containerize Go and SQLite with Docker

#50
post #23

If you are using Go (which solves most of your dependency problems) and SQLite (which means you don't need to integrate with an external database via service discovery) why do you need Docker at all?

Because the deployment environment is or may be a Kubernetes cluster or some other kind of containerized environment. Wrapping up your application in a neat package makes other people's jobs easier - to them, it's a black box container, not a binary they need to install and manage on a server.
Post reply on HN