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

Awesome Docker Compose Examples

github.com

Post reply on HN
Print view View original

51–60 of 85 posts

Re: Awesome Docker Compose Examples

#51

Post by newman314 »

AgentK20 wrote: post #22
capableweb wrote: post #19

Earlier quoted context omitted.

> Using @-hashes doesn't assure you of not getting pwned the same way here It does, changes to the image could be pushed to "latest" or a specific tag, but the hash cannot change, once you've established that a specific hash is secure, it'll remain secure (or rather, as secure as you first established it as).

I think the parent comments point was that it’s difficult, if not impossible, to verify the security of even a particular hash. It’s still vulnerable to the same dependency chain vulnerabilities as pinning to latest, but instead locking in a particular version and _hoping_ that it wasn’t pwned. Additionally, you are then not getting any exploit fixes that may be included in newer versions, so even if there was a vuln…

This is one task that Dependabot excels at.

You can use a image like golang:1.20.1-alpine3.17@sha256:48f336ef8366b9d6246293e3047259d0f614ee167db1869bdbc343d6e09aed8a and be able to both see the version (human-parseable)and the hash (machine-parseable)

Dependabot will update both the version and hash parts of the tag in a pull request. Pretty magical if you ask me. I haven't found a way for it to auto-apply yet but Renovate can do it if you want automatic updates.

Re: Awesome Docker Compose Examples

#52

Post by fbdab103 »

sneak wrote: post #47
fbdab103 wrote: post #8

Earlier quoted context omitted.

This looks great. Definitely a few idioms I will have to explore further. I can use Docker in a basic sense, but it is amazing to me how much black arts still exists for what has become a cornerstone of modern deployment. Lots of conflicting/dated advice about best practices. Unsure which advice is still required/applies to podman, etc.

> but it is amazing to me how much black arts still exists for what has become a cornerstone of modern deployment. What?! Unless you are using complicated networking, docker is simple. Dockerfiles are essentially just annoying-syntax shell scripts. We have plenty of black arts in computing. Docker isn't one of them.

So, am I still supposed to specify UID and GID? Should I be using Alpine or Debian? How do I handle loading certificates? Should I use an override config for development? In this thread, someone was indicating that the naive volume option does not work over SSH. Also in this thread was a request to pin by tag and not hash. Do I still need to worry about Docker blowing a hole in iptables?

Maybe not black magic, but there are a lot of subtle optimizations for which there is much conflicting guidance.

Re: Awesome Docker Compose Examples

#53

Post by davepeck »

krick wrote: post #49
davepeck wrote: post #13

Earlier quoted context omitted.

These are excellent, thank you. I maintain similar Django and Flask + compose stacks on behalf of the startup studio I work for so it’s fun to compare notes. For our Django stack, for instance, we have also settled on Postgres, on celery+redis, and on whitenoise. black/flake8/isort also seem universally agreeable. We also throw in pyright and generally make extensive use of type hints. For the front-end, we’re curren…

Offtopic, but I've googled Tailwind because of this comment. This seems absolutely crazy to me, in the worst sense imaginable. So, there was (and still is) "style" attribute in HTML. It leads to lots of repetition and yadda yadda, so people started using classes instead to write their CSS. There are dozens of schools of "best practices", or meta-frameworks, or actual frameworks to make it all more manageable, but now…

Hah! This was pretty much my response when I encountered Tailwind for the first time.

This post by Tailwind’s author gives some more perspective: https://adamwathan.me/css-utility-classes-and-separation-of-...

Re: Awesome Docker Compose Examples

#54

Post by smaccona »

fbdab103 wrote: post #52
sneak wrote: post #47

Earlier quoted context omitted.

> but it is amazing to me how much black arts still exists for what has become a cornerstone of modern deployment. What?! Unless you are using complicated networking, docker is simple. Dockerfiles are essentially just annoying-syntax shell scripts. We have plenty of black arts in computing. Docker isn't one of them.

So, am I still supposed to specify UID and GID? Should I be using Alpine or Debian? How do I handle loading certificates? Should I use an override config for development? In this thread, someone was indicating that the naive volume option does not work over SSH. Also in this thread was a request to pin by tag and not hash. Do I still need to worry about Docker blowing a hole in iptables? Maybe not black magic, but th…

This is how people end up using Kubernetes, despite its warts.

[edit: added second clause]

Re: Awesome Docker Compose Examples

#55

Post by guffins »

krick wrote: post #50
throwawaaarrgh wrote: post #40

FWIW the standard now says the file should be called "compose.yaml"; "docker-compose.yaml" is supported but deprecated

Ambitious decision. As if docket-compose is the only tool that uses the word compose, and there is no other extremely common tool, that uses for configuration, for instance, files like composer.json and composer.lock.

I’m on my phone and haven’t double checked this, but from my understanding, I believe it’s part of an effort to encourage compatibility with other tools like podman. The ambiguity is somewhat intentional, as an active decision to separate the implementation name from the configuration standard.

Re: Awesome Docker Compose Examples

#56

Post by Too »

throwawaaarrgh wrote: post #40

FWIW the standard now says the file should be called "compose.yaml"; "docker-compose.yaml" is supported but deprecated

Equally confusing and often misunderstood is that the latest version of a compose file should not have a version field at all!

It is a blend of v2, v3 and any newly added attributes (v3 some times supported less than v2), that is now called the compose spec.

Implementations are supposed to do feature detection based on what attributes are used in the file. Make sure your docker compose is new enough, otherwise it thinks absence of version field means v1!

Re: Awesome Docker Compose Examples

#57

Post by gonzo41 »

Terretta wrote: post #32
gonzo41 wrote: post #26

Nice examples. I personally really love compose. For all the complexity in the container space it really nails down a fanatic experience.

> I personally really love compose. For all the complexity in the container space it really nails down a fanatic experience. Fanatics love docker, for sure. It's… fantastic!

Lol, I didn't catch that. You know what I mean.

Re: Awesome Docker Compose Examples

#58

Post by quest88 »

nickjj wrote: post #6

There's a lot of "tool" selections in that repo. If anyone is looking for ready to go web app examples aimed at both development and production with Docker Compose, I maintain: - https://github.com/nickjj/docker-flask-example - https://github.com/nickjj/docker-rails-example - https://github.com/nickjj/docker-django-example - https://github.com/nickjj/docker-node-example - https://github.com/nickjj/docker-phoenix-exam…

Does this start rails app and postgre db on the same server?

Re: Awesome Docker Compose Examples

#59

Post by glenngillen »

gonzo41 wrote: post #26

Nice examples. I personally really love compose. For all the complexity in the container space it really nails down a fanatic experience.

Might not totally be a coincidence that it started life as an independent thing to give Docker a better experience, that Docker then acquired/acqui-hired.

Re: Awesome Docker Compose Examples

#60

Post by throwawaaarrgh »

Too wrote: post #56
throwawaaarrgh wrote: post #40

FWIW the standard now says the file should be called "compose.yaml"; "docker-compose.yaml" is supported but deprecated

Equally confusing and often misunderstood is that the latest version of a compose file should not have a version field at all! It is a blend of v2, v3 and any newly added attributes (v3 some times supported less than v2), that is now called the compose spec. Implementations are supposed to do feature detection based on what attributes are used in the file. Make sure your docker compose is new enough, otherwise it thi…

Yeah I was gonna complain about this but honestly I don't even know what the hell they're doing with the version field anymore. I suspect it's because they want to force you to upgrade because otherwise they may have to support legacy longer.
Post reply on HN