#docker (2020-01)

docker

All things docker

Archive: https://archive.sweetops.com/docker/

2020-01-13

Szymon avatar

Hi, I have Centos7 Jenkins Agent where I build my docker images. In Dockerfile I run yarn install and some packages are trying to create their directories under node-modules dir. I realized that SELinux is somehow preventing of doing so, because with SELinux enabled, I see permission denied error. When I disable SELinux, it works. I’m not an Centos/SeLinux expert - can you advise me how can I tune SELinux settings to fix that without disabling SeLinux?

Daren avatar
Daren
06:55:24 PM

@Daren has joined the channel

2020-01-22

Dzhuneyt avatar
Dzhuneyt

I am using Docker Swarm to orchestrate a couple of DigitalOcean machines. However, often those machines encounter OOM and crash, leading to Swarm failure (especially when the crashing machine is a Swarm manager). How do I effectively protect the Swarm against such issues? I assumed the Docker Swarm should have knowledge of the available memory on every Swarm member and prevent scheduling containers on machines that are running low on memory.

Dzhuneyt avatar
Dzhuneyt

I realize that provisioning larger capacity than required (e.g. adding extra Swarm members) may mitigate to some degree, but the cost overhead is to be taken into account. Is there a more elegant solution that doesn’t involve over-povisioning infrastructure or catastrophic failure of the Swarm everytime we fail to predict accurately the sum of consumed memory by all running Docker containers in the Swarm (something that is fairly variable and hard to calculate in advance)?

Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)

@Dzhuneyt I’m not familiar with swarm in particular, but with kubernetes this is what the requests and limits are used for. Without a these, kubernetes cannot possibly know where it should schedule a container to ensure enough memory will be available when it’s needed. For the same reason, I think Swarm must have something analagous for this as well.

Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)

(also digital ocean has managed kubernetes - maybe “upgrade” )

2020-01-29

Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)
Alpine makes Python Docker builds 50× slower, and images 2× largerattachment image

When you’re choosing a base image for your Docker image, Alpine Linux is often recommended. Using Alpine, you’re told, will make your images smaller and speed up your builds. And if you’re using Go that’s reasonable advice. But if you’re using Python, Alpine Linux will quite often: Make your builds much slower. Make your images bigger. Waste your time. On occassion, introduce obscure runtime bugs. Let’s see why Alpine is recommended, and why you probably shouldn’t use it for your Python application.

roth.andy avatar
roth.andy

Also:

  1. Alpine’s CVE database is garbage compared to alternatives
  2. It’s not just python. Support is spotty for a variety of tools due to alpine not being a commonly supported and tested distro
Alpine makes Python Docker builds 50× slower, and images 2× largerattachment image

When you’re choosing a base image for your Docker image, Alpine Linux is often recommended. Using Alpine, you’re told, will make your images smaller and speed up your builds. And if you’re using Go that’s reasonable advice. But if you’re using Python, Alpine Linux will quite often: Make your builds much slower. Make your images bigger. Waste your time. On occassion, introduce obscure runtime bugs. Let’s see why Alpine is recommended, and why you probably shouldn’t use it for your Python application.

Maciek Strömich avatar
Maciek Strömich

yeah, we dropped alpine linux for exactly the same purpose some time ago and went with multistage builds based on vanilla ubuntu resulting in ~300MB deployment images.

roth.andy avatar
roth.andy

bitnami/minideb has been my go-to lately, but since we do mostly gov work we’ll be switching to their sponsored Universal Base Image which is RHEL but doesn’t require a license (they made some kind of special deal with Red Hat)

roth.andy avatar
roth.andy
Introducing the Red Hat Universal Base Image

With the release of the Red Hat Universal Base Image (UBI), you can now take advantage of the greater reliability, security, and performance of official Red Hat container images where OCI-compliant Linux containers run - whether you’re a customer or not. This means you can build a containerized application on UBI, push it to a container registry server of your choosing, and share it. The Red Hat Universal Base Image can allow you to build, share and collaborate on your containerized application where you want.

Maciek Strömich avatar
Maciek Strömich

as far as i understand if you don’t have a rhel subscription you’re not able to download all rhel content

1

2020-01-30

    keyboard_arrow_up