Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Containerize Go and SQLite with Docker

awstip.com

Post reply on HN
Print view View original

81–90 of 90 posts

Re: Containerize Go and SQLite with Docker

#81

Post by encryptluks2 »

hvidgaard wrote: post #65
ramoz wrote: post #55

Earlier quoted context omitted.

I’ve honestly not touched docker in years, but all of my prod apps run in docker. So it’d be paradoxical for me to see I don’t need docker, but I really want to.

Docker can be considered a deployment tool. You package your application in an image and run said image. Development and test of that application does not have to be in a docker image.

Nor does deployment. Podman, Rancher, etc all solve those challenges without relying on Docker and with Docker changing their licensing I don't think it will be the de-facto tool in a couple years. There will be others that will replace it.

Re: Containerize Go and SQLite with Docker

#82

Post by encryptluks2 »

jrockway wrote: post #31
encryptluks2 wrote: post #28

Earlier quoted context omitted.

Docker isn't a cache-all for containers. Docker has a pretty terrible deployment story at this point and I forsee in a couple years it will probably be considered legacy compared to Podman/K3d/Local K8s/etc

I think people use the word Docker to mean "produce an OCI-compliant image that a CRI runtime can run".

Podman does the same thing, as well as other tools. Using Docker to refer to something that doesn't use Docker is like saying that your Android Phone is an iPhone.

Re: Containerize Go and SQLite with Docker

#83

Post by chriswarbo »

nerdponx wrote: post #78
lbayes wrote: post #71

Earlier quoted context omitted.

The claim that horizontal scaling is free with Docker is simply not accurate. Maybe it will be some day, but these orchestration and deployment tools built on Docker have enormous hidden costs. IME, Docker takes an enormous amount of focus away from the customer problem and moves it to the how to get this mess working problem. Now may be the right time in a given business to make that shift in focus, but to claim tha…

> IME, Docker takes an enormous amount of focus away from the customer problem and moves it to the how to get this mess working problem. This is the opposite in my experience: Docker lets me focus on the business problem by making deployment easier.

Docker lets me focus on cool problems like "which commands can I use to free up space on this cloud-based container-running VM, given that there are 0 bytes free, and many tools will crash if they can't make a tempfile/dir?".

At least, that's been my experience when maintaining a mess of other people's Docker crap.

Re: Containerize Go and SQLite with Docker

#84

Post by hsn915 »

rob74 wrote: post #42
alexjurkiewicz wrote: post #27

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...

Yea, Docker is crazy to me. I can never understand people who think it's awesome or something. It's awful.

Of course, if you're doing somethign in Python/Ruby/Node.js then it's useful because these language do not provide a reliable method to compile source code into an independent program/application.

But that does not make it "awesome" or anything. It's just a band-aid. It's an extra layer to hide fundamental design problems.

With Go, the root problem is solved: the language has a compiler that reliably produces statically linked binary executable programs.

Re: Containerize Go and SQLite with Docker

#85

Post by atmosx »

nerdponx wrote: post #79
atmosx wrote: post #74

Testing locally, adding the "-linkmode external -extldflags '-static'" flags doesn't bring down the binary size. The heavy lifting is done by '-s -w'. It is a good idea to drop privileges even if there's a small attack surface. At $work we use the following template. Sharing in case you find it interesting: FROM golang:1.17.1-alpine3.14 as builder RUN apk update && apk add ca-certificates curl git make tzdata RUN add…

What do you use the SSL certs in the container for? I always have run Docker behind either a reverse proxy like Nginx or in some kind of cloud platform that handles SSL at the perimeter.

Certs are used by the client to perform validation when initiating HTTP calls to APIs.

Re: Containerize Go and SQLite with Docker

#86

Post by fivea »

ramoz wrote: post #55
fivea wrote: post #40

Earlier quoted context omitted.

> Docker has a pretty terrible deployment story (...) This is the very first time I ever heard such nonsense. In all companies I've been, Docker is a renowned problem solver, not only for production deplyments but also for local testing environments and deployments. It even shines as a stand-alone barebones clustering solution with Docker swarm mode.

I’ve honestly not touched docker in years, but all of my prod apps run in docker. So it’d be paradoxical for me to see I don’t need docker, but I really want to.

> So it’d be paradoxical for me to see I don’t need docker, but I really want to.

I find it quite amusing that projects that try to position themselves as Docker alternatives end up basing their presentation on how their project can be used just like Docker, down to Docker's choice of command line interface.

Re: Containerize Go and SQLite with Docker

#87

Post by Okawari »

ttwwmm wrote: 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?

Uniformity perhaps? I for one help manage several workloads that has become quite a lot easier to manage through containers and I'dd rather deal with that than having a few workloads being deployed differently from everything else. Maybe containerizing a go project like this is more work than strictly necessary, it would be a quick 10 line Dockerfile and pretty much done.

Re: Containerize Go and SQLite with Docker

#88

Post by hvidgaard »

encryptluks2 wrote: post #81
hvidgaard wrote: post #65

Earlier quoted context omitted.

Docker can be considered a deployment tool. You package your application in an image and run said image. Development and test of that application does not have to be in a docker image.

Nor does deployment. Podman, Rancher, etc all solve those challenges without relying on Docker and with Docker changing their licensing I don't think it will be the de-facto tool in a couple years. There will be others that will replace it.

Docker has become synonymous with OCI images, and my comment was exactly in that context (or at least state of mind) - I should have stated that as well.

Re: Containerize Go and SQLite with Docker

#89

Post by pstuart »

mkdirp wrote: post #44
pstuart wrote: post #5

Earlier quoted context omitted.

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 d…

I must confess to copypasta for this approach. Yes, stack traces are incredibly valuable. The upx compression itself does seem to be a no-brainer with the exception of any situation where that 150ms time actually matters.

Re: Containerize Go and SQLite with Docker

#90

Post by fivea »

lbayes wrote: post #68
fivea wrote: post #38

Earlier quoted context omitted.

> 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? Dependencies is not really a problem with Docker, nor the thing it is designed to solve. If dependencies was the problem people cared about, everyone would just go with the single statically linked executable/fat JAR a…

Okay, I'll bite. > It's also a deployment format that provides horizontal scaling for free. Um. Docker does not provide horizontal scaling at all, for that you need orchestration. And those tools are anything but free if your time has any value.

> Um. Docker does not provide horizontal scaling at all, for that you need orchestration.

It does. Please take the time to learn about Docker and it's Docker swarm feature.

Post reply on HN