CODEWITHSUNDEEP
dockerpip
Jack
Jack

Reputation: 3

Installing python pip for docker container doesnt work

I'm trying to configure python-pip for my docker container(s). But it gives me the error that I dont have permission. After I use sudo, it gives me an another error.

I'v tried using sudo for root permission. I aslo tried the command exec and run.

sudo docker container run davidrazd/discord-node-10 sudo apt-get install python-pip
sudo docker container exec davidrazd/discord-node-10 sudo apt-get install python-pip

docker: Error response from daemon: OCI runtime create failed: container_linux.go:348: starting container process caused "exec: \"sudo\": executable file not found in $PATH": unknown.

And without sudo:

E: Could not open lock file /var/lib/dpkg/lock-frontend - open (13: Permission denied)

E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), are you root?

Upvotes: 0

Views: 1578

Answers (1)

erik258
erik258

Reputation: 16304

Here's 3 reasons I think you should reconsider your use of Docker and make sure you're getting the most out of containers.

  1. you have an image called ...-node-10. You shouldn't need specific images for specific nodes. They should all run on the same image and, to the extent necessary, be configured at runtime (this should be kept to a minimum, usually things like discovery or dynamic config). If 10 is a version, you should be using tags to version it, not image ID itself.

  2. There's a valid use case for one-off execution of an install within a running container via exec for one-off package installs (knowing that the install will disappear when the container stops), but docker run ... apt-get install really doesn't make sense to me. As @DavidMaze points out in a question comment, installs that are meant to be should always be part of the Dockerfile. If you're installing packages to long-lived containers - don't, and don't. The worst things that happen to folks with docker is they attempt to treat containers as long lived Virtual Machines, when they should be treating them as ephemeral runtime environments that maintain minimal state, are essentially immutable ( and therefore easily replaced by the next version), their image contains all their install-time dependencies, and store any long term data on a separate docker volume (that hopefully is itself backed up).

  3. You're likely configuring a user your application to run as a USER in your Dockerfile but you're attempting to run privileged commands without setting your USER to something else. Then you attempt to run sudo. But sudo doesn't make much sense in the context of a container, and typically is not installed (and if it was, it would mean you'd have to somehow set up a user to sudo, so it wouldn't make your life any easier, just harder). You can set your user at docker exec time to root with docker exec -u root .... But you shouldn't really need to do this - all setup should be done in the Dockerfile and you should ship a new dockerfile to change versions.

I'm a very heavy user of docker myself, and build nearly all applications in it becuse it so vastly simplifies expressing their runtime requirements, so I think I speak from the voice of experience here. You won't get any of the value of docker if your containers aren't immutable; you'll just have the same problems as you would without containers, but with less management tooling. Docker obviates most of the management at runtime - capitalize on that, don't fight it.

Upvotes: 2

Related Questions