We are running windows 2019 Server Core OS image in our container. By default my container supports all the following protocols
TLS
TLS1.1
TLS1.2
My application is using ssl3 for some request. I want to enable ssl3 on the container
I tried editing the registry on container, but it requires a restart for windows to recognize change in registry related to ssl3. Since in docker, there is no concept of restarting windows inside container, how can I enable ssl3 protocol on windows docker 2019 image.
Can i use init containers for changing windows registry. If so, how?
I am also to any other options
Extra Information
I am using following command to know ssl3 is not there on windows 2019 Server OS container.
nmap --script ssl-enum-ciphers -p 443 mysite.com --unprivileged
I am getting following output
SSL3 is not supported on Azure Containers
Related
i need some help for installing kyma locally.
I was following the official guide:
https://kyma-project.io/docs/kyma/latest/04-operation-guides/operations/02-install-kyma/
I have:
Windows 10
Hyper-V activated
Docker Desktop installed (v4.9.1)
Kubernetes (1.24.0) - shown by kubectl version --client
K3d (v5.4.3)
kyma-cli 2.0.4
kubernetes-helm 3.8.2
I installed it like this:
Starting up Docker Desktop
kyma provision k3d
kyma deploy
While deploying now, i get some errors, which tell me, that some essential components can not be deployed:
Errors
Can you help me solve this so that i can start up a functional kyma instance?
Greetings and thanks in advance!
The issue was the kubernetes version. After downgrading my docker desktop to 4.1, which is using kubernetes 1.21 it works now.
As of version 1.20, Kubernetes deprecated Docker as a container runtime in favor of containerd. Due to a different way in which containerd handles certificate authorities, Kyma's built-in Docker registry does not work correctly on clusters running with a self-signed TLS certificate on top of Kubernetes installation where containerd is used as a container runtime.
If that is your case, either upgrade the cluster to use Docker instead of containerd, generate a valid TLS certificate for your Kyma instance or configure an external Docker registry.
another way is to disable kubernetes provided by docker-desktop and use the command below to provision kubernetes cluster based on k3d
kyma provision k3d
I've been following this tutorial to set up an Azure container service. I can successfully connect to the master load balancer via putty. However, I'm having trouble connecting to the Azure container via docker.
~ docker -H 192.168.33.400:2375 ps -a
error during connect: Get https://192.168.33.400:2375/v1.30/containers/json?all=1: dial tcp 192.168.33.400:2375: connectex: No connection could be made because the target machine actively refused it.
I've also tried
~ docker -H 127.0.0.1:2375 ps -a
This causes the docker terminal to hang forever.
192.168.33.400 is my docker machine ip.
My guess is I haven't setup the tunneling correctly and this has something to do with how docker runs on Windows 8.1 (via VM).
I've created an environment variable called DOCKER_HOST with a value of 2375. I've also tried changing the value to 192.168.33.400:2375.
I've tried the following tunnels in putty,
1. L2375 192.168.33.400:2375
2. L2375 127.0.0.1:2375
3. L22375 192.168.33.400:2375
4. L22375 127.0.0.1:2375 (as shown in the video)
Does anyone have any ideas/suggestions?
Here are some screenshots of the commands I ran:
We can follow this steps to setup tunnel:
1.Add Azure container service FQDN to Putty:
2.Add private key(PPK) to Putty:
3.Add tunnel information to Putty:
Then we can use cmd to test it:
The problem. I am trying to create a TeamCity infrastructure (a server and an agent) on Ubuntu Linux 16.04.1 LTS using Docker. I have run a Docker container with jetbrains/teamcity-server image as described on this page. It is possible to access the TeamCity server via web browser using the IP address of the server and port 8111.
Now I try to run a Docker container with an agent as described on this page. It is written: Note that "localhost" will not generally not work as that will refer to the "localhost" inside the container. Well, when I supply "http://localhost:8111", or "http://127.0.0.1:8111", or "http://my_server_ip:8111" to the running script for the agent container I finally get 1) "WARN - buildServer.AGENT.registration - Error registering on the server via URL http://localhost:8111 (sic! always localhost). Will continue repeating connection attempts.", or 2) "WARN - buildServer.AGENT.registration - Error while asking server for the communication protocols via URL http://localhost:8111/app/agents/protocols."
Also I have tried to reveal the IP address of the Docker container running the server and supply it for the agent running script. But the result was the same.
Question. What server URL I should provide? Are there any implicit steps in the TeamCity configuration with Docker which I miss?
You can use the --link parameter to link containers:
Start your jetbrains/teamcity-server and use --name teamcity-server to give it a descriptive name
Start the agent container and use --link teamcity-server to enable connectivity to the teamcity-server container
Inside of your agent container you can now use teamcity-server as the hostname to connect to the teamcity-server container
Please also check out Docker container networking which superseded the --link feature.
I am trying to use the Docker Remote API on a Windows 10 host machine. I am using Chrome's Postman extension to see if I can get results from the docker remote api's endpoints. Here are the endpoints that I've tried:
GET http://192.168.99.100:4243/images/json
GET http://192.168.99.100:2376/images/json
Both returned Connection to server 192.168.99.100 failed (The server is not responding)
After a few searches I found out that the Docker Remote API is not enabled by default on Windows. Most of the guides are for Ubuntu but I have found this particular one for Windows.
These are the steps that I performed on my machine
docker-machine ssh
cd /var/lib/boot2docker
sudo vi profile
Change DOCKER_HOST='H tcp://0.0.0.2376' to DOCKER_HOST='H tcp://0.0.0.2375'
change DOCKER_TLS=auto to DOCKER_TLS=no
export DOCKER_HOST='-H tcp://0.0.0.2375'
export DOCKER_TLS_VERIFY=0
env | grep DOCKER
docker-machine restart
docker-machine env
docker-machine regenerate-certs
After performing the steps above, I did try again the endpoints on Postman but I still get the same result.
Can you perhaps give a little help if I have missed a step? Or am I on track?
Also, to answer some of my queries.
Is the docker remote api port for Windows 2375 and 4243 for Linux?
Is DOCKER_HOST for Windows and DOCKER_OPTS for Linux?
Switch your docker to windows container
Got to C:\ProgramData\Docker\config
in deamon.json file
add "hosts": ["tcp://0.0.0.0:2376", "npipe://"]
restart docker.
give command : docker -H tcp://0.0.0.0:2376 ps
The Remote API is now enabled by default on Windows (see ticket here).
It is reachable at http:\\localhost:2375 indeed (tested it).
I faced the same issue and found a quick solution for this. Just open docker settings and enable "Expose daemon on TCP..." checkbox. Docker will start automatically and the problem should be solved.Please find the image attached for reference
using docker desktop, go to settings and check "Expose daemon on tcp://localhost:2375 without TLS"
I have an Ubuntu 16.04 (Xenial) running inside an Azure VM. I have followed the instructions to install Docker and all seems fine and dandy.
One of the things that I need to do when I trigger docker run is to pass --net=host, which allows me to run apt-get update and other internet-dependent commands within the container.
The problem comes in when I try to trigger docker build based on an existing Ubuntu image. It fails:
The problem here is that there is no way to pass --net=host to the build command. I see that there are issues open on the Docker GitHub (#20987, #10324) but no clear resolution.
There is an existing answer on Stack Overflow that covers the scenario I want, but that doesn't work within a cloud VM.
Any thoughts on what might be happening?
UPDATE 1:
Here is the docker version output:
Client:
Version: 1.12.0
API version: 1.24
Go version: go1.6.3
Git commit: 8eab29e
Built: Thu Jul 28 22:11:10 2016
OS/Arch: linux/amd64
Server:
Version: 1.12.0
API version: 1.24
Go version: go1.6.3
Git commit: 8eab29e
Built: Thu Jul 28 22:11:10 2016
OS/Arch: linux/amd64
UPDATE 2:
Here is the output from docker network ls:
NETWORK ID NAME DRIVER SCOPE
aa69fa066700 bridge bridge local
1bd082a62ab3 host host local
629eacc3b77e none null local
Another approach would be to try letting docker-machine provision the VM for you and see if that works. There is a provider for Azure, so you should be able to set your subscription id on a local Docker client (Windows or Linux) and follow the instructions to get a new VM provisioned with Docker and it will also setup your local environment variables to communicate with the Docker VM instance remotely. After it is setup running docker ps or docker run locally would run the commands as if you were running them on the VM. Example:
#Name at end should be all lower case or it will fail.
docker-machine create --driver azure --azure-subscription-id <omitted> --azure-image canonical:ubuntuserver:16.04.0-LTS:16.04.201608150 --azure-size Standard_A0 azureubuntu
#Partial output, see docker-machine resource group in Azure portal
Running pre-create checks...
(azureubuntu) Completed machine pre-create checks.
Creating machine...
(azureubuntu) Querying existing resource group. name="docker-machine"
(azureubuntu) Resource group "docker-machine" already exists.
(azureubuntu) Configuring availability set. name="docker-machine"
(azureubuntu) Configuring network security group. location="westus" name="azureubuntu-firewall"
(azureubuntu) Querying if virtual network already exists. name="docker-machine-vnet" location="westus"
(azureubuntu) Configuring subnet. vnet="docker-machine-vnet" cidr="192.168.0.0/16" name="docker-machine"
(azureubuntu) Creating public IP address. name="azureubuntu-ip" static=false
(azureubuntu) Creating network interface. name="azureubuntu-nic"
(azureubuntu) Creating virtual machine. osImage="canonical:ubuntuserver:16.04.0-LTS:16.04.201608150" name="azureubuntu" location="westus" size="Standard_A0" username="docker-user"
Waiting for machine to be running, this may take a few minutes...
Detecting operating system of created instance...
Waiting for SSH to be available...
Detecting the provisioner...
Provisioning with ubuntu(systemd)...
Installing Docker...
Copying certs to the local machine directory...
Copying certs to the remote machine...
Setting Docker configuration on the remote daemon...
Checking connection to Docker...
Docker is up and running!
To see how to connect your Docker Client to the Docker Engine running on this virtual machine, run: docker-machine env azureubuntu
#Set environment using PowerShell (or login to the new VM) and see containers on remote host
docker-machine env azureubuntu | Invoke-Expression
docker info
docker network inspect bridge
#Build a local docker project using the remote VM
docker build MyProject
docker images
#To clean up the Azure resources for a machine (you can create multiple, also check docker-machine resource group in Azure portal)
docker-machine rm azureubuntu
Best I can tell that is working fine. I was able to build a debian:wheezy DockerFile that uses apt-get on the Azure VM without any issues. This should allow the containers to run using the default bridged network as well instead of the host network.
According to I can't get Docker containers to access the internet? using sudo systemctl restart docker might help, or enable net.ipv4.ip_forward = 1 or disable the firewall.
Also you may need to update the dns servers in /etc/resolv.conf on the VM