I am working on launching Consul containers on docker with Marathon and I've run into a somewhat subjective issue regarding creating the JSON files.
Currently I plan to launch containers with JSON files of this format
server-1.json
{
"id": "consul-server-2",
"cmd": "consul agent -server -client=0.0.0.0 -ui -bind=100.10.30.40 -retry-join=server-1.local -data-dir=/tmp/consul",
"cpus": 1,
"mem": 512.0,
"instances": 1,
"container": {
"type": "DOCKER",
"docker": {
"image": "consul:latest",
"name": "dev-consul",
"network": "HOST"
}
},
"constraints": [
[
"hostname",
"CLUSTER",
"server-1.local"
]
]
}
I need to be able to change the -bind address for each JSON file and I was planning on using heredocs with BASH but I am not sure if there are better practices as far as ease of maintainability for creating these type of files.
Ideally I would have liked to have a field in Consul or Marathon which could automatically give me the IP address of a specific port to feed to -bind but because I have multiple private IPs it seems I need to configure it manually.
It sounds like you have a configuration management issue.
If I understand you correctly you have a number of servers in an internal network where each has an internal IP address and you now want to generate the right service files for each server.
Typically you would use a configuration management system like e.g. Ansible, Chef or Puppet to solve this.
Personally I can recommend Ansible since it is easy to get started with and low overhead.
To solve your problem you would then first create an inventory file with the IP addresses of your servers and then create a Jinja2 template for your service files.
You can then use the correct IP address for each server in that template and finally deploy all the files with Ansible.
Look at consul 0.7.2 or newer. There is a soon-to-be documented feature in Consul that allows for runtime configuration of IP addresses. I wouldn't recommend running Consul in a container unless running net=host, but using the configuration snippet above:
{
"id": "consul-server-2",
"cmd": "consul agent -server -client='{{ GetPrivateIP }}' -ui -bind=100.10.30.40 -retry-join=server-1.local -data-dir=/tmp/consul",
"cpus": 1,
"mem": 512.0,
"instances": 1,
"container": {
"type": "DOCKER",
"docker": {
"image": "consul:latest",
"name": "dev-consul",
"network": "HOST"
}
},
"constraints": [
[
"hostname",
"CLUSTER",
"server-1.local"
]
]
}
Other options for what address to use can be explored based on the hashicorp/go-sockaddr package.
Related
I'm trying to deploy a spring boot project to azure using docker containers.
If I do az container logs --name ... --resource-group ... I see
Tomcat started on port(s): 80 (http) with context path ''
az container show --name ... --resource-group ...
"ipAddress": {
"dnsNameLabel": "X",
"dnsNameLabelReusePolicy": "Unsecure",
"fqdn": "X.centralus.azurecontainer.io",
"ip": "Y",
"ports": [
{
"port": 80,
"protocol": "TCP"
}
],
"type": "Public"
},
Now if I go to X.centralus.azurecontainer.io I only see 404 page not found and don't see any request being made in the logs for the spring container (have logs set to debug to see if it serves anything)
On the azure portal it also confirms that my container is in state "Running"
For what reasons does "page not found" show instead of just forwarding to the container on the same port? Anyone know what could be wrong here?
• I would highly recommend you to please refer to the below Microsoft documentation links for troubleshooting common Azure Spring cloud application deployment issues and in general issues faced while deploying an Azure Container Instance. As they are quite helpful in resolving the common issues faced by users regarding Azure Container Instances.
https://learn.microsoft.com/en-us/azure/container-instances/container-instances-troubleshooting
https://learn.microsoft.com/en-us/azure/spring-cloud/troubleshoot
I'm using Docker on a Window 10 laptop. I recently tried to get some code to run in a container to connect to another server on the network. I ended up making a Ubuntu container and found the issue is a IP conflict between the docker network and the server resource (172.17.1.3).
There appears to be an additional layer of networking on the Windows Docker setup with isn't present on the Unix system, and the docker comments to "simply using a bridge network" doesn't resolve this issue.
docker network inspect bridge
[
{
"Name": "bridge",
"Id": "d60dd1169153e8299a7039e798d9c313f860e33af1b604d05566da0396e5db19",
"Created": "2020-02-28T15:24:32.531675705Z",
"Scope": "local",
"Driver": "bridge",
"EnableIPv6": false,
"IPAM": {
"Driver": "default",
"Options": null,
"Config": [
{
"Subnet": "172.17.0.0/16",
"Gateway": "172.17.0.1"
}
]
},
"Internal": false,
"Attachable": false,
"Ingress": false,
"ConfigFrom": {
"Network": ""
},
"ConfigOnly": false,
"Containers": {},
"Options": {
"com.docker.network.bridge.default_bridge": "true",
"com.docker.network.bridge.enable_icc": "true",
"com.docker.network.bridge.enable_ip_masquerade": "true",
"com.docker.network.bridge.host_binding_ipv4": "0.0.0.0",
"com.docker.network.bridge.name": "docker0",
"com.docker.network.driver.mtu": "1500"
},
"Labels": {}
}
]
Is it possible to change the subnet/gateway to avoid the IP conflict? If so how? I tried the simple thing and making a new docker network:
docker network create --driver=bridge --subnet=172.15.0.0/28 --gateway=172.15.0.1 new_subnet_1
There still appears to have a conflict somewhere, I can reach other devices just nothing in 172.17.0.0/16. I assume guessing it's somewhere in the HyperV, vEthernet adapter, or vswitch.
UPDATE 1
I took a look at wireshark (PC level) with the new_subnet_1 network and I did not see these packets leave the vSwitch interface or the PC's NIC.
I did see this Docker forum which is indicating an issue with the Hyper-V and V-switch that could be the issue.
Docker Engine v19.03.5
DockerDesktopVM created by Docker for Windows install
UPDATE 2
After several Hyper-v edits and putting the environment back together I check the DockerDesktopVm. After getting in from a privileged container I found that the docker0 network had the IP conflict. Docker0 is appears to be the same default bridge network that I was avoiding, because it is a pre-defined network it cannot be removed, and all my traffic is being sent to it.
After several offshoots, and breaking my environment at least once, I found that the solution was easier then I had though.
Tuned off Docker Desktop Services
Added the following line to the %userprofile%\.docker\deamon.json file in windows 10
....lse,
"bip": "172.15.1.6/24" <<new non conflicting range
}
Restarted Docker Desktop Service
Easy solution after chasing options in Hyper-V and the Docker Host Linux VM.
I was able to get onDomain working, but someone in the Slack channel stated that onDomain is deprecated for Traefik, though there is no mention of deprecation in the Traefik documentation.
[edit]
There is a reference to this deprecation here: https://github.com/containous/traefik/issues/2212
I am using the Consul catalog backend with host rules for my services, being set with tags:
ex:
{
"service": {
"name": "application-java",
"tags": ["application-java", "env-SUBDOMAIN", "traefik.tags=loadbalanced", "traefik.frontend.rule=Host:SUBDOMAIN.domain.com"],
"address": "",
"port": 8080,
"enable_tag_override": false,
"checks": [{
"http": "http://localhost:8080/api/health",
"interval": "10s"
}]
}
}
However, no certificate is generated for SUBDOMAIN.domain.com - requests just use the TRAEFIK DEFAULT CERT.
What is the recommended method for getting Traefik to generate certificates for Consul catalog services automatically?
It looks like this might only work with the frontEndRule option in the main config, rather than with the "traefik.frontend.rule" override tag.
I added this line:
frontEndRule = "Host:{{getTag \"traefik.subdomain\" .Attributes
.ServiceName }}.{{.Domain}}"
and this Consul catalog tag:
traefik.subdomain=SUBDOMAIN
and I'm getting the Fake certificate from the LE staging server now.
I'm using dnsmasq but I'm a little confused as to what gets set where. Everything works as expected, but I wasn't sure if any of my config parameters are redundant or would cause issues down the road.
1 - Do I need to set the recusors option in Consul's config?
2 - Do I still need both nameservers entry in /etc/resolv.conf?
3 - Do I need dnsmasq on all Consul clients or just the servers?
#/etc/dnsmasq.d/dnsmasq.conf`
server=/consul/127.0.0.1#8600
My Consul config looks like this:
{
"server": false,
"client_addr": "0.0.0.0",
"bind_addr": "0.0.0.0",
"datacenter": "us-east-1",
"advertise_addr": "172.16.11.144",
"data_dir": "/var/consul",
"encrypt": "XXXXXXXXXXXXX",
"retry_join_ec2": {
"tag_key": "SOMEKEY",
"tag_value": "SOMEVALUE"
},
"log_level": "INFO",
"recursors" : [ "172.31.33.2" ],
"enable_syslog": true
}
My /etc/resolv.conf looks like this:
nameserver 127.0.0.1
nameserver 172.31.33.2
1) read the documentation: https://www.consul.io/docs/agent/options.html#recursors having a recursor setup is great if you have external services registered in Consul, otherwise it's probably moot. You likely don't want ALL of your DNS traffic to hit consul directly, just the consul specific DNS traffic.
2 & 3:
It's up to you. Some people run dnsmasq on every machine. Some people centralize dnsmasq on their internal DNS servers. Both are valid configurations. If you run it on every single machine, then you probably just need 1 nameserver entry, pointed at localhost. If you run it centralized (i.e. just on your internal DNS servers) then you just point every machine at your internal DNS servers. Both are valid options.
I have ec2 instance running and which is linked with elastic ip.
when I ping it from local machine then It shows request time out because of which I am not able connect to it via putty and win scp.
I am facing this issue from last 2days.
It was working well for last 2 months.
Please help.
My instance is runig and healthy.
If you want to ping an EC2 instance from your local machine you need to allow inbound Internet Control Message Protocol (ICMP) traffic. Please check your Security Groups to make sure this is allowed. Remember that all inbound traffic is disable by default. You may need to establish a rule similar to this one (JSON format):
"AllowIngressICMP": {
"Type": "AWS::EC2::SecurityGroupIngress",
"Properties": {
"GroupId": <Your Security Group here>,
"IpProtocol": "icmp",
"FromPort": "-I",
"ToPort": "-I",
"CidrIp": "0.0.0.0/0"
** The -I means "every port"