Prisma1: Prisma-CLI should have its own Docker image

[graph1zzlle]

Is your feature request related to a problem? Please describe.
While trying to orchestrate Prisma for development & production deployment, I find it is not convenient that prisma-cli does not have its own Docker container. I tend to run everything using Docker containers, I do not want to install Prisma (e.g npm install -g prisma) on my system.

Describe the solution you'd like
Publish two separate between Docker image for prisma-cli & prisma-server.

Describe alternatives you've considered
I can build a Docker image that fits my needs by doing a Dockerfile by myself.

[pantharshit00]

@graph1zzlle

I think think there is not a very genuine use case for a CLI to be wrapped inside a docker container. If you want you can easily make one using the node image.

Also, prisma generate only requires prisma.yml and datamodel.graphql file to generate the clients.

If you are trying to avoid npm, we publish the cli on homebrew and we also a linux binary(download it from here: https://s3-eu-west-1.amazonaws.com/curl-linux/prisma-1.26.3.tar.gz. You can also use this binary inside docker if you want.

Also, there are plans for prisma to be a standalone library and prisma server would be optional so don't think it makes sense to publish the cli as a docker image. https://github.com/prisma/prisma/issues/2992

[pantharshit00]

Also, please ping if strongly disagree @graph1zzlle

[graph1zzlle]

@pantharshit00 Thanks for your answer. I do not strongly disagree, I understand and don't mind doing my own tooling. Still, here is my opinions:

• The Prisma Docker image naming, prismagraphql/prisma, does not reflect really reflect what it really is: prisma-server
• Homebrew and Linux Binary is not a satisfying solution for me. I want to programmatically encode my development & deploy process using docker-compose, .env files and a couple of bash scripts. I want it to be portable and reproducible (e.g everything needed to deploy & dev my app live in my git repositiry), without relying on any kind of state where something is already installed.
• I want my prisma-cli version to be in sync with prisma-server, without having to worry if my local installation is out of date or not compared to prisma-server version. I want it to be defined in one place, e.g .env file, and I can inject it anywhere I want to pull the right Docker container version for both

[steebchen]

@pantharshit00 I strongly disagree; it is super useful when you use Kubernetes and you want to deploy Prisma using initContainers before your API server starts to let prisma do its migrations. For this, I need a container image with my code and the Prisma CLI, and it would be helpful if you could just do FROM prisma/client or FROM prisma/cli in my docker image. Right now I just build the docker image myself, but I think it would be great if there was an official one.

[pantharshit00]

Actually, I will prefer a community maintained solution now since Prisma 2 will not be centered around Docker.

[LongLiveCHIEF]

These days, i don't install _anything_ from my development projects natively... not even the programming language. It's _all_ docker. I'm not a fan of prisma implying you have to have an OS to start a prisma project.

I did open some issues on the existing docker documentation (which you guys took care of thanks!), and I also did something of my own about it to help the community members who had the same approach as me.

I basically dockerized the howtographql.com backend tutorials, and did a write up along with scripts and images of how I dockerized prisma-cli.

You can find everything in the README of https://github.com/LongLiveCHIEF/docker-howtographql,

[LongLiveCHIEF]

Actually, I will prefer a community maintained solution now since Prisma 2 will not be centered around Docker.

Forgive me for saying so, but this is somewhat naive considering the infrastructure landscape where your project is going to be deployed. It's more likely than not that prisma would be run on containerized infrastructure in any real world deployment scenario.

Might I recommend inviting community members who specialize in docker to be collaborators and maintainers and ask them to support the docker parts, so that you don't have diverging community of docker offerings that may not be the best because they don't have the benefit of insight from the projects core maintainers?

[LongLiveCHIEF]

...and yes, that's an offer, as long as I have backing and cooperation of core maintainers to add other docker maintainers as needed.