Docker build has no network, but docker run has - build

If I want to build my Dockerfile, it can't connect to the network or at least DNS:
Sending build context to Docker daemon 15.95 MB
Sending build context to Docker daemon
Step 0 : FROM ruby
---> eeb85dfaa855
Step 1 : RUN apt-get update -qq && apt-get install -y build-essential libpq-dev
---> Running in ec8cbd41bcff
W: Failed to fetch http://httpredir.debian.org/debian/dists/jessie/InRelease
W: Failed to fetch http://httpredir.debian.org/debian/dists/jessie-updates/InRelease
W: Failed to fetch http://security.debian.org/dists/jessie/updates/InRelease
W: Failed to fetch http://httpredir.debian.org/debian/dists/jessie/Release.gpg Could not resolve 'httpredir.debian.org'
W: Failed to fetch http://httpredir.debian.org/debian/dists/jessie-updates/Release.gpg Could not resolve 'httpredir.debian.org'
W: Failed to fetch http://security.debian.org/dists/jessie/updates/Release.gpg Could not resolve 'security.debian.org'
W: Some index files failed to download. They have been ignored, or old ones used instead.
Reading package lists...
Building dependency tree...
Reading state information...
E: Unable to locate package build-essential
INFO[0001] The command "/bin/sh -c apt-get update -qq && apt-get install -y build-essential libpq-dev" returned a non-zero code: 100
But if I run exactly the same command via docker run it works:
docker run --name="test" ruby /bin/sh -c 'apt-get update -qq && apt-get install -y build-essential libpq-dev'
Does anybody have an idea, why docker build does not work? I have tried all DNS related tipps on StackOverflow, like starting docker with --dns 8.8.8.8 etc.
Thanks in advance

Check what networks are available on your host with the below command:
docker network ls
then pick one that you know is working, the host one could be a good candidate.
Now assuming you are in the directory where it is available your Dokerfile, build your image appending the flag --networks and change the <image-name> with yours:
docker build . -t <image-name> --no-cache --network=host

Docker definitely seems to have some network issues. I managed to fix this problem with
systemctl restart docker
... which is basically just the unix-level 'restart-the-daemon' command in Debian 8.

I had similar problem. But as I was running AWS linux i had no systemctl. I solved using:
sudo service docker restart

My docker build also failed while trying to run apt-get upgrade with the exact same errors. I was using docker-machine on Mac OSX and a simple docker-machine restart default solved this issue. No idea what initially caused this, though.

Another case of the above reported behaviour - this time building a docker image from Jenkins:
[...]
Step 3 : RUN apt-get update && apt-get install -y curl libapache2-mod-proxy-html
---> Running in ea7aca5dea9b
Err http://security.debian.org jessie/updates InRelease
Err http://security.debian.org jessie/updates Release.gpg
Could not resolve 'security.debian.org'
Err http://httpredir.debian.org jessie InRelease
[...]
In my case it turned out that the DNS wasn't reachable from within the container - but still from the docker host !? (The containers resolver configuration was okay(!))
After restarting the docker machine (a complete reboot - a 'docker.service restart' didn't do the trick) it's been working again.
So one of my activities (or of a colleague of mine) must have broken the docker networking then !?? Maybe some firewalld modification activity ???
I'm still investigating as I'm not sure which activity may have corrupted the docker networking then ...

I have the exact same issue with a Raspberry.
Start/stopping the service did not help, but re-installing the package (dpkg -i docker-hypriot_1.10.3-1_armhf.deb && service docker start in my case) immediately solved the situation : apt-get update manages to resolve and reach the servers.
There must be some one-shot actions in the installation process...

Also faced the same issue today. My workaround was to restart your docker-machine. In my case, it's on VirtualBox.
Once you power off it and then restart the machine, http://security.debian.org seemed resolved.
Hope this helps.

A couple of suggestions, not sure if they will work or not. Can you change the ...apt-get install -y... to ...apt-get install -yqq...
Also, has that image changed that you're trying to build from?

Related

Can't get CloudWatchAgent to start on Ubuntu18.04 in Docker build for AWS Batch job

I'm trying build an image for use on EC2 instances in an AWS Batch job. I need to use Ubuntu 18.04 because the goal is to run some Fortran software that I can only get to compile on Ubuntu 18.04. I have the Fortran software and some python scripts running well on a manually started Ubuntu 18.04 EC2 instance.
Now, I'm trying to build an image with Docker (that I'll eventually apply to 100s or 1000s of EC2 instances)... but I have to get CloudWatchAgent (CWA) installed and started, and I can't get CWA to start in the Docker build. CWA starts and runs fine in my manual EC2 development instance (Ubuntu 18.04). I initially had problems with CWA in my manual instance because CWA uses systemctl, and so I had to manually install systemd, and that worked after a reboot. But, I'm not able to replicate this in my Docker build, but always get the error:
System has not been booted with systemd as init system (PID 1). Can't operate.
unknown init system
The command '/bin/sh -c sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -s -c file:amazon-cloudwatch-agent.json' returned a non-zero code: 1
I tried starting with an ubuntu 18.04 image that is supposed to have systemd already installed, and tried rebooting my EC2 instance, same error. Here's the source: https://hub.docker.com/r/jrei/systemd-ubuntu
I looked for other ideas, e.g.: Docker System has not been booted with systemd as init system
... but couldn't figure out how to make it work in a Docker build.
So,
am I using the Ubuntu 18.04 image (that has systemd) in my build wrong- how to use in a Docker build?
is there another way to start CloudWatchAgent in Ubuntu 18.04 that gets around the systemd problem?
would it work/is there a way to restart the operating system inside the Docker container, during the docker build stage?
am I stuck and will have to try recompile everything on a different Ubuntu or AMI like Amazon Linux?
Or is there something else I'm missing?
Here's my Docker file:
#version with systemd already installed
FROM jrei/systemd-ubuntu#sha256:1b65424e0ec4f6772576b55c49e1470ba506504d1033e9da5795785b1d6a4d88 as ubuntu-base
RUN apt-get update && apt-get install -y \
sudo \
wget \
python3-pip
RUN sudo apt-get -y install libgfortran3
RUN sudo pip3 install boto3
RUN wget https://s3.us-east-2.amazonaws.com/amazoncloudwatch-agent-us-east-2/ubuntu/amd64/latest/amazon-cloudwatch-agent.deb
RUN sudo dpkg -i -E ./amazon-cloudwatch-agent.deb
COPY . .
RUN cp amazon-cloudwatch-agent.json /opt/aws/amazon-cloudwatch-agent/etc/
ENV ECS_AVAILABLE_LOGGING_DRIVERS = awslogs
RUN sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -s -c file:amazon-cloudwatch-agent.json
RUN mkdir -p cpseqlogs
CMD python3 cpsequence.py
Thanks for any suggestions, ideas, or tips (I'm fairly new to Docker, but not totally green on linux).

can't start minikube in ec2 shows "X Sorry, Kubernetes v1.18.0 requires conntrack to be installed in root's path"

Hi I am trying to start minikube that's why I ran
minikube start --vm-driver=none
But it shows in the console the below lines:
minikube v1.9.2 on Amazon 2 (Xen/amd64)
Using the none driver based on user configuration
X Sorry, Kubernetes v1.18.0 requires conntrack to be installed in root's path
Note that i have installed kubectl minikube and docker.
Please help me to sort out this issues.
I had the same issue. Install 'conntrack' with
sudo apt install conntrack
Then continue to start your minikube:
sudo minikube start --vm-driver=none
Execute following commands
yum install conntrack
start minikube as root
start --driver=none
TL;DR : update minkikube
You need minkikube not older than v1.9.0-beta
It's a known issue
There is a known issue #7179 reproduced in 1.18
Fixed in Pull Request #7180, the latest commit is 1273d4f:
install conntrack for github action integration tests #7180
Minimal minikube ver that contain commit 1273d4f is v1.9.0-beta:
git clone https://github.com/kubernetes/minikube/
cd minikube
git describe 1273d4f8e756ac5eca89d94c449450fb2da21a5a
>v1.9.0-beta.2-16-g1273d4f8e
Explanation of git describe
Explanation of git describe is here
The command is useful for cases such as:
which tag is closest to the commit? (git describe <sha>)
which tag contains commit? (git describe <sha> --contains)
which branch or annotated tag is closest to the commit? (git describe <sha>--all)
On CentOS 7, run following command:
yum install conntrack
And don't forget to have at least 2 (v)CPUs
You need to install conntrack:
apt-get install conntrack -y
and then you can run the minikube start command again
minikube start --vm-driver=none
make sure you do it as a root user or prefix sudo.
If your running ubuntu, make sure you systemd and kubeadm already installed. I found that this resolved for me
sudo apt-get update && sudo apt-get install -y apt-transport-https curl
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
at <<EOF | sudo tee /etc/apt/sources.list.d/kubernetes.list
deb https://apt.kubernetes.io/ kubernetes-xenial main
EOF
sudo apt-get update
sudo apt-get install -y kubelet kubeadm kubectl
sudo apt-mark hold kubelet kubeadm kubectl
Reference Links:
https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-
https://minikube.sigs.k8s.io/docs/drivers/none/
I use the following command to resolve the issue:
minikube start --vm-driver=docker

startup script yum install fails with "signature could not be verified for google-cloud-sdk"

I reran the startup script using following command:
sudo google_metadata_script_runner --script-type startup
All the yum install commands are failing with following error:
startup-script: INFO startup-script-url: Retrieving key from https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
startup-script: INFO startup-script-url: https://packages.cloud.google.com/yum/repos/cloud-sdk-el7-x86_64/repodata/repomd.xml: [Errno -1] repomd.xml signature could not be verified for google-cloud-sdk
startup-script: INFO startup-script-url: Trying other mirror.
startup-script: INFO startup-script-url: One of the configured repositories failed (Google Cloud SDK),
Any idea how I could fix this while instance provisioning or any workaround?
To be honest I have found this on google, not sure if this helps but maybe you can try it out anyway.
1) Disable Caching in yum config /etc/yum.conf:
http_caching=none
2) Delete tmp yum files:
rm -r /var/tmp/yum*
3) restart machines
4) cleanup yum:
yum clean metadata
yum clean all
yum update
I am trying to reproduce the issue on my end. It would be helpful if you could share the information below:
What is the exact OS you are using here.
What happens when you are trying to run the scripts manually after VM starts.
Can you please share the sample script without the confidential information or credentials.
Though I have not tested this, the error can happen due to yum not having enough cached data to continue. And the solution can be found on the public: https://community.cloudera.com/t5/Support-Questions/yum-doesn-t-have-enough-cached-data-to-continue/m-p/220862
I just encountered this same error on a Docker build.
Google Cloud's (latest) repo configuration is as follows:
[google-cloud-cli]
name=Google Cloud CLI
baseurl=https://packages.cloud.google.com/yum/repos/cloud-sdk-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=0
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
Our Dockerfile yum repo configuration had to be corrected from repo_gpgcheck=1 to repo_gpgcheck=0 and then the error went away.
For me running yum-config-manager --disable google-cloud-sdk solved it. I got this from the error message that I got:
...
4. Disable the repository permanently, so yum won't use it by default. Yum
will then just ignore the repository until you permanently enable it
again or use --enablerepo for temporary usage:
yum-config-manager --disable google-cloud-sdk
or
subscription-manager repos --disable=google-cloud-sdk
In case anyone's facing same issue with apt. Can try --
curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key --keyring /usr/share/keyrings/cloud.google.gpg add -

installing php-imap on amazon ec2 linux 2

I need to install php-imap on amazon ec2 linux 2 instance.
All the php stuff is inside amzn2extra-lamp-mariadb10.2-php7.2 but php-imap package is missing.
Any advice ?
Thanks
I installed it like this.
I downloaded the php source code of the currently installed version in my Amazon Linux 2
wget http://php.net/get/php-7.2.8.tar.bz2/from/a/mirror
Unpacked it and went into php-7.2.8/ext/imap/
Compiled extension:
phpize
./configure
I got some errors.
Some U8T_CANONICAL stuff so
sudo yum install libc-client-devel
Then libc-client.a not found so created a symlink for it:
cd /usr/lib
sudo ln -s /usr/lib64/libc-client.a
some other imap library error so:
sudo yum install uw-imap-static
I got some other errors so the working configure line was:
./configure --with-kerberos --with-imap-ssl
make
SUCCESS!
cd php-7.2.8/ext/imap/modules
sudo cp imap.so /usr/lib64/php/modules/
Created an ini file to load it:
sudo vi /etc/php.d/30-imap.ini
added to the file this content:
extension=imap
restarted php service (you might need to restart httpd depending on your php installation):
sudo systemctl restart php-fpm
PHPinfo now contains:
imap
IMAP c-Client Version 2007f
SSL Support enabled
Kerberos Support enabled
For those who are facing the U8T_CANONICAL error and can't being able to install the libc-client-devel on Amazon Linux 2 AMI need to do something extra to resolve the U8T_CANONICAL error.
The main problem is that libc-client-devel isn't available so we need to do it in another way.
I found this link while searching for my problem. The solution that is posted here is solid. The following link that i gave is for those who are not being able to install the libc-client-devel will be benifited from the link.
Or you could just copy paste the commands i'm giving below.
1 - sudo yum groupinstall "Development Tools"
2 - sudo amazon-linux-extras install epel
3 - yum install epel-release
4 - sudo yum install libc-client-devel uw-imap-static openssl-devel
5 - sudo ln -s /usr/lib64/libc-client.a /usr/lib
The rest can be followed from respondent.
Again thanks to the person who answered.
Same problem here.
I came from debian/ubuntu and i miss a lot of php packages on aws linux2.
I know it's still a candidate and not a final LTS release. Only worked for a month with this distro and saw a lot of changes and updates. Some php dependencies can be solved with pear or pecl, but I couldn't get nothing working on php-imap.
php-imap depends on libc-client (maybe that's a problem?)
Here is my solution.
Search for the libc-client rpm that correspond to your version and
install manually.
Search for the rpm that corresponds to your php installed version. In my case it was 7.2.5**-2** about 2 weeks ago. (today is
7.2.5**-3** ) and isntall manually
CODE
wget https://dl.iuscommunity.org/pub/ius/stable/CentOS/7/x86_64//php72u-imap-7.2.5-2.ius.centos7.x86_64.rpm -P /tmp
wget http://dl.fedoraproject.org/pub/epel/7/x86_64/Packages/l/libc-client-2007f-16.el7.x86_64.rpm -P /tmp
rpm -i /tmp/libc-client-2007f-16.el7.x86_64.rpm
rpm -i /tmp/php72u-imap-7.2.5-2.ius.centos7.x86_64.rpm
If it fails because Failed dependencies:
rpm -ivh /tmp/php72u-imap-7.2.5-2.ius.centos7.x86_64.rpm --nodeps
I dont like this solution, but can't find for now any other solution more stable and easy. It will be a pain with updates....

php56-common conflicts with php-common-5.3.29-1.8.amzn1.x86_64 when installing phpmyadmin

I have successfully installed php70 and mysql. But when i am trying to install phpmyadmin by
$ sudo yum-config-manager --enable epel
And Then
$ sudo yum install -y phpMyAdmin
It gives me
--> Finished Dependency Resolution
Error: php70-common conflicts with php-common-5.3.29-1.8.amzn1.x86_64
Error: php56-common conflicts with php-common-5.3.29-1.8.amzn1.x86_64
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest
Also after google sometimes i found a solution that try this
sudo yum install php70-mbstring
And i have tried this also, Still facing same error.
Any suggestion...?
I guess that you are following the Amazon tutorial to install phpMyAdmin ?
I had the same problem today and resolved it by uninstall PHP 7.0 with the yum command (the same given by Amazon with 'remove' instead of 'install' :
sudo yum remove httpd24 php70 mysql56-server php70-mysqlnd
and installed PHP 5.6 instead :
sudo yum install httpd24 php56 mysql56-server php56-mysqlnd
I don't know if this is a good solution, but it worked and I could install phpMyAdmin without dependencies problem. I hope it will help :)
In case you want to keep php7, I found a solution with AWS Amazon experts.
Just use :
sudo yum install -y php70-mbstring
I was having the same issue today. I had some success downloading phpmyadmin from phpmyadmin.net, and following their instructions. I did run into a different problem during the setup of phpmyadmin....
So, I punted on resolving this with the Amazon AMI for now, and chose to install the Bitnami LAMP AMI to get me going quicker. It comes with phpmyadmin configured.
NOTE: Bitnami's AMI is running PHP Version 5.6.29, so I would say it's valid to follow the previous post's advice and downgrade, unless your web application specifically needs PHP 7.0.