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

61–70 of 90 posts

Re: Containerize Go and SQLite with Docker

#61

Post by cpach »

fivea wrote: post #41
cpach wrote: post #34

Earlier quoted context omitted.

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

Oh. TIL. Sounds very useful!

Re: Containerize Go and SQLite with Docker

#62

Post by mariusor »

password4321 wrote: post #21

> C libraries are required to interact with SQLite Or: modernc.org/sqlite (plus https://github.com/zombiezen/go-sqlite ), "an automatically generated translation of the original C source code of SQLite into Go" as mentioned yesterday: https://news.ycombinator.com/item?id=29959193#29960726

This article is just an example of someone that encountered a problem and didn't do their due diligence of finding the best solution for their use case.

The discussion of building fully static go binaries for docker has been rehashed a million times on the internet, the modernc.org/sqlite is at version 3+, so nothing in this should be new information for anyone that has an interest in the topic.

I strongly dislike this type of content that just repacks basic existing information and uses it as an excuse to click bait people on to a spammy blog.

Re: Containerize Go and SQLite with Docker

#63

Post by zibzab »

maccard wrote: post #58
rob74 wrote: post #42

Earlier quoted context omitted.

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

> all you have to do is compile a binary and copy it to the server Docker does this quite well, and solves a bunch of other problems you're likely to have regardless. One really simple example is "how do you copy it to the server?" Do you have ssh keys for your server on development machines? How do you handle the "Oh I'll just remote in and fix this one X"? It's also _crazily_ easy to get started with, and handle mi…

I don't get this answer.

Publishing your docker image to some open or private store still needs to happen. Then the host needs to be updated. This is not really that much simpler than "scp your binaries to the server". And has many more moving parts that can fail.

Now, there are better ways to distribute go projects than scp, for example heroku style or by just abusing its builtin git support.

Re: Containerize Go and SQLite with Docker

#65

Post by hvidgaard »

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.

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.

Re: Containerize Go and SQLite with Docker

#66

Post by hardwaresofton »

harpratap wrote: post #35
hardwaresofton wrote: post #20

Earlier quoted context omitted.

Also, before `kubectl debug`[0] existed, you could always edit a Deployment and add a sidecar container of `alpine` or `busybox` and enable process namespace sharing[1] get some leverage to debug with. A bunch of other options in the docs as well [0]: https://kubernetes.io/docs/tasks/debug-application-cluster/d... [1]: https://kubernetes.io/docs/tasks/configure-pod-container/sha...

That would trigger a restart, no? What if you want to live debug without restarting the scratch container?

Yup it would trigger a restart -- that first link details some other options if restarting the workload is absolutely not an option. You can debug a copy, start a privileged pod, or jump on to the node and actually enter the namespace manually. At the end of the day all these containers are just sandboxed+namespaced processes running on a machine somewhere, so if you can get on that machine with the appropriate permissions then you can get to the process and debug it.

Of course, if you're in a tightly managed environment and can't get on the nodes themselves things get harder, but probably not completely impossible :)

Re: Containerize Go and SQLite with Docker

#67

Post by lbayes »

It's hard to believe anyone is still promoting Docker.

Has anyone actually used it?

If you haven't jumped on the bandwagon yet, don't do it. It's a sucker's game.

I got sucked into the Docker hype some years ago and the demos worked well enough in isolation.

I pushed it on a small team that didn't need it. One of the biggest regrets of my career.

Docker may be useful if an application has enormous reach and needs Google scale, but very few apps do.

1) It is incredibly slow to build

2) It is slow to run

3) It is an unbelievable resource hog

4) It has an entirely new set of problems (file system, networking, etc.) that must be understood to get it working

5) Hard deploy time dependency on Docker's web app?!

6) If you do not believe me on the complexity, just observe how docker arguments always seem to turn into k8s (or other orchestration) arguments. It is hard to reason about, hard to deploy, hard to coordinate.

K8s is a total disaster for a small team working on a small project.

We lost many months by choosing these tools for a startup that didn't (yet) need them, and the ongoing, neverending pile of problems and distractions they generated was shocking.

I still feel bad about it. The company could have run on a couple $400 machines under a desk for years, but instead spent tens of thousands on AWS services it didn't need.

Of course, YMMV

Re: Containerize Go and SQLite with Docker

#68

Post by lbayes »

fivea wrote: post #38
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?

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

Re: Containerize Go and SQLite with Docker

#69

Post by [deleted] »

yread wrote: post #49
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?

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

[deleted]

Re: Containerize Go and SQLite with Docker

#70

Post by krat0sprakhar »

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.

I think what the OP means that using Docker you can use tools that give horizontal scaling for free (see: Cloud Run etc.)
Post reply on HN