#Looking through the cookbooks
topaz lotus
Starting a thread to avoid flooding everyone
@tribal hare it depends on the situation. We're not pushing one way or the other. When you have a Dockerfile and it works fine, keep it. If you find yourself generating or templatizing Dockerfiles on the fly, or pulling an image then manually "finishing it" with docker run invocations, or if managing too many build args becomes a problem.. Then it's a natural transition to building in code.
tribal hare
ok
topaz lotus
If you're going Dagger-native, and don't have legacy tooling, maybe you don't need the Dockerfile at all, depending on your workflow
tribal hare
So if people aren't running docker in production, then maybe they don't need a Dockerfile and lots of different docker-compose run invokations .. they can just use native code ..
is that inline with your opinion (above)?
topaz lotus
It's orthogonal to using Docker in production
Docker in production can run any container regardless of how it was built
And Dagger has built-in Dockerfile compatibility, so you can switch any of your container builds to Dagger at any time, whether you keep the Dockerfile or not.
There was a blog post about this general topic a while back, here it is : https://dagger.io/blog/replace-dockerfile-with-go
tribal hare
Here's a question.
Can someone do the .from(), .withExec(), or directory() ..etc
and then "snapshot" that state and tag it as a docker image?
🙂
Meaning you don't need a Dockerfile, for all the layers .. you can use Dagger for all the layers .. and then "freeze" it and then you get a valid image generated .. in the end
ha! I think you just answered my theory/question with your blog post link ..
Configure a container with all required dependencies and environment variables
Download and build the application source code in the container
Set the container entrypoint
Publish the built container image to Docker Hub
It says "publish" to docker hub at the end .. whihc was my idea
am I on the same wavelength as you, here?
topaz lotus
Yes, you can do this at any time (as long as you mean pushing to a registry)
the Container core type in Dagger can be translated to/from an OCI image at any time
tribal hare
aye, I'm familair with OCI and buildkit and so on.. from my years as a docker subject matter expert
i'm learning how Dagger takes advantage to it, from a DX perspective, thus my questions\
I think I have some USP's here, for PHP community
Replace nasty Dockerfiles and crappy YML Files .. and instead use PHP to define all the things
USPs for developers
- replace Dockerfile, with code .. and then just publish it
- replace docker-compose.yml with code
- replace many different "docker run / docker-compose run" invokations with simple code
Anything else comes to mind @topaz lotus ? I'll focus on these key USPs as examples, for the conference (in 2-3 days time)
topaz lotus
If your audience is php developers, they may wonder "why?"
The sweet spot for Dagger is when devops and CI starts becoming a problem. Typically that's when you have dev siloes that need to work together (ie. frontend / backend / data, each with their own tools and languages).
In theory, CI is supposed to solve that: Jenkins or CircleCI or Github Actions become the common ground. Except in practice, it's a shit experience.
So Dagger offers a better common ground for dev siloes that need to work together to ship a product. It lets you standardize how to build, test, lint, deploy, across the whole stack. And it lets you do it incrementally, because it works with your existing tools. So you don' thave to throw everything away. You just pick one part of your stack that is slowing you down, and you daggerize it until it's not. Then you move on to the next problem etc.