Closed carolynvs closed 4 years ago
I'll open a proposal PR and we can iterate on that.
FYI, I think we had second thoughts on where it should live. Since it's generic and probably won't be owned by someone outside of our core team (like maybe the azure mixin will be) I think it will be easier to put it in cmd/docker and pkg/docker for now.
Yeah, I think in tree
makes sense for this and the kubernetes one (#82). We should maybe come up with some criteria later on on what makes sense to be in and out.
A docker
mixin would allow people to use the docker cli inside of a bundle. It would not include the compose cli (that would be a separate mixin).
It is important for this mixin for people to be able to specify the version of the CLI that they want downloaded (by default they get the latest). See If you are having trouble downloading the docker binary, it may help (not sure it's been a while) to use the Docker Version Manager to download it for you. https://github.com/howtowhale/dvm/
If you would like to make a mixin for this request, use our template. The readme will explain how to make the mixin. The mixin should wrap the cli and expose the pack
cli commands. An example of a mixin made from the template is porter-aws that also shows how to configure the mixin to download a specific version. You could also look at porter-helm to see how it figures out on the fly which version the server has and downloads it automatically (dvm can help with that too).
:wave:
The mixin should wrap the cli and expose the pack cli commands.
Hey it was all clear until that bit. We're referring to https://buildpacks.io/docs/install-pack/?
Further questions:
exec
mixin now to run docker stack deploy ...
and I guess that this is the mixin that should exist for me to do that more declaratively within the porter.yaml
?@decentral1se I'm so sorry for missing your question! I was just coming back to read it because I have someone ready to work on this, @gaurimadhok is starting this week on the Docker mixin. I didn't mean to ignore your message...
I mis-typed when I said pack. Not sure what my fingers were thinking? I mean that common commands like docker build
and docker push
for example should be exposed directly through the mixin's DSL. We are initially targeting build, run, pull, and push. stack deploy
would be another good one to support, so we will have to add an issue for that too! 👍
The goal is that someone wouldn't need to manually install docker themselves in a custom Dockerfile, or have to fall back to the exec mixin, even for commands that the mixin doesn't have nice DSL support for. So if we don't have stack deploy
implemented in the DSL (e.g. a simplified yaml syntax), you can still use the docker mixin to execute a custom command similar to how you use exec today to run it. That way you aren't juggling two different mixins to work with the same tool.
Can mixins be written in any language of choice or Go only?
Mixins can be in any language! 🎉 They need to support a set of commands that porter expects and know how to communicate with porter over stdin/stdout. If you use Go, there are helpers that you can rely upon because we've written so many mixins already in Go. But we would love to see mixins in other languages and helpers to support them. 👍
Here's the documentation on how to create a mixin https://porter.sh/mixin-dev-guide/
Would something like #1057 be handled by this mixin?
Did Vaughn help answer your question about injecting secrets into your container in that issue? If not, please let me know and we can clarify what exactly needs to be fixed or added to make that work in time for v1.0.
This may need to live in a new repository (similar to porter-helm and porter-azure). It should allow a user to execute a docker container (an invocation image from the bundle).
Let's figure out some scenarios and example yaml first before we start writing any code though.