All geek questions in one place

Work with a large binary file (3 GB) in docker and Jenkins

I use the google model (binary: about 3 GB) in my docker file, and then use Jenkins to create and deploy it on a production server. The rest of the code is pulled from the bitpack repository.

An example line from a docker file where I download and unzip a file. This happens only once when this command is cached.

FROM python:2.7.13-onbuild RUN mkdir -p /usr/src/app WORKDIR /usr/src/app ARG DEBIAN_FRONTEND=noninteractive RUN apt-get update && apt-get install --assume-yes apt-utils RUN apt-get update && apt-get install -y curl RUN apt-get update && apt-get install -y unzip RUN curl -o - https://s3.amazonaws.com/dl4j-distribution/GoogleNews-vectors-negative300.bin.gz \ | gunzip > /usr/src/app/GoogleNews-vectors-negative300.bin

Everything works fine when I create and run docker on my local machine. However, when I make a patch version to push these changes to the production server through Jenkins, my build process fails. Installation, assembly, and testing phases work fine. However, the post-build phase is not performed. (The build process pushes the changes to the repo, and according to the logs, all the commands in the docker file also work fine.) After that, something happens and I get the following error when viewing the logs.

 18:49:27 654f45ecb7e3: Layer already exists 18:49:27 2c40c66f7667: Layer already exists 18:49:27 97108d083e01: Pushed 18:49:31 35a4b123c0a3: Pushed 18:50:10 1e730b4fb0a6: Pushed 18:53:46 error parsing HTTP 413 response body: invalid character '<' looking for beginning of value: "<html>\r\n<head><title>413 Request `Entity Too Large</title></head>\r\n<body bgcolor=\"white\">\r\n<center>`<h1>413 Request Entity Too Large</h1></center>\r\n<hr> center>nginx/1.10.1</center>\r\n</body>\r\n</html>\r\n"

Maybe the file is too large?

Before adding this file, everything with docker and Jenkins worked fine too.

I am wondering if there are any limitations in docker / Jenkins when processing a large file like this? or am I breaking something as I approach him.

Update: Increasing client_max_body_size resolved this specific error. However, I get another error when ssh -o StrictHostKeyChecking=no root@ipaddress "cd /root/ourapi &&docker-compose pull api &&docker-compose -p somefolder up -d"

Docking does not work here with unexpected success. It tries to download an image (1.6 GB), but will cancel it after almost approaching that size, and then try again, which ends with an eof error.

What leads me to the old question, if in this situation you need to process large files?

Update 2: Problem resolved. I needed to increase client_max_body_size to 4 GB and also increase the timeout parameter for pulling the repository from our own repository server. Setting these two parameters led to a solution to the problem.

+5
source share
1 answer

The problem was caused mainly for the following reasons:

  • The default value of client_max_body_size in the Ngnix server configuration was very low. Because of this, we were not able to download a 3.6 GB file, so we increased this value to 4 GB.
  • We run the Jetty server in our repository management system to serve HTTP traffic, so we need to increase the wait time for Jenkins to get the appropriate docker files out of it.

This answer is mainly related to this particular problem. However, the question of how to handle such files better remains open. Moreover, it is unclear whether increasing client_max_body_size to 4 GB is a good idea in general.

Relevant docs for client_max_body_size: http://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size

+1
source

Source: https://habr.com/ru/post/1270298/

More articles:


All Articles