I am experimenting with apache2 websites running within LXD containers. I can access the websites from
the internet, however one of the functions of the website is not working.
I have an iframe on the page that will not connect. The “src” of the iframe is local to the container. So the iframe looks like this:
is HTML code that is rendered by your web browser. Therefore, the URL should not have been localhost, because localhost is the computer that runs your Web browser.
You need to replace it with the proper hostname that you use to access this Apache2 server.
So I used your article about " How to Host Multiple Web Sites with Nginx and HAProxy Using LXD on Ubuntu 16.04" This works fine for accessing the website inside the container from the internet.
But the webpage in the container has an iFrame inside it that will not connect. I have a video player running on port 3000 in the same container. That is why I use localhost.
I have tried using: 127.0.0.1, localhost, lpc1.streamingworld.us as the src in the iFrame and none of them will connect?
My container is LPC1. From inside the container I can ping LPC1.lxd. From the HOST, I cannot ping LPC1.lxd.
Again, I can access the webpage from the internet. It’s the iFrame src that will not connect.
Here are the headers from the Chrome network console:
This error is something very specific and relates to the way that the website is set up.
You can get a Let’s Encrypt certificate for lpc1.streamingworld.us and add that to the streaming server.
If you set up using a reverse proxy, then you setup the Let’s Encrypt certificate(s) on the reverse proxy that is fronting your containers. Thus, you do not need to setup certificates in any containers.
Otherwise, you would need to setup TLS to each website in the containers.
I do not know what software is running on the lpc1:3000 service. If it is something that gets direct access to the Internet, then you need to see how you can add TLS support to it. The same certificate for lpc1 can be used for lpc1:3000.
To fix these errors, please make sure that your domain name was
entered correctly and the DNS A/AAAA record(s) for that domain
contain(s) the right IP address. Additionally, please check that
your computer has a publicly routable IP address and that no
firewalls are preventing the server from communicating with the
client. If you’re using the webroot plugin, you should also verify
that you are serving files from the webroot path you provided.
# Test URI to see if its a letsencrypt request
acl letsencrypt-acl path_beg /.well-known/acme-challenge/
use_backend letsencrypt-backend if letsencrypt-acl
# it matches if the http host: field mentions any of the hostnames (after the '-i').
acl host_LPC1 hdr(host) -i lpc1.streamingworld.us
#acl host_LPC2 hdr(host) -i lpc2.streamingworld.us
# Redirect the connection to the proper server container, depending on the match.
use_backend cont_LPC1 if host_LPC1
#use_backend cont_LPC2 if host LPC2
# LE Backend
backend letsencrypt-backend
server letsencrypt 127.0.0.1:8888
backend cont_LPC1
balance leastconn
# We set the X-Client-IP HTTP header. This is useful if we want the web server to know the real client IP.
http-request set-header X-Client-IP %[src]
# This backend, named here "LPC1", directs to container "LPC1.lxd" (hostname).
server LPC1 LPC1.lxd:80 check
# backend cont_LPC2
# balance leastconn
# http-request set-header X-Client-IP %[src]
# server LPC2 LPC2.lxd:80 check
Is there a difference between using Haproxy on the host versus using Haproxy in a separate container?
Right now I am using a container for haproxy and I have incoming http on port 80 of the host iptable’ed to
the haproxy container. Like your tutorial specifies.
Both work, haproxy on the host and haproxy in a container. The main difference is that in the latter, you need to use iptables to forward both port 80 and 443 to the haproxy container.
Indeed, that’s the proper way to run certbot. Do you run this from within the haproxy container? If so, then most likely you do not have port 8888 forwarded from the host to the container. Alternatively, you can use the default port (i.e. 80), shutdown temporarily haproxy, then run certbot. certbot will get the certificates and you can then install them in haproxy. certbot will be able to accept the connection from the Let’s Encrypt servers through the port 80 port forwarding.
Your haproxy container does not have a public IP, meaning that it is not directly accessible from the Internet.
And, Let’s Encrypt needs you to pass a challenge in order to verify that you are owner of your claimed domain name. The http-01 challenge requires from the Let’s Encrypt server to connect back to your server and retrieve the challenge file. However, in the case of your container, anything that runs in the container is inaccessible from the Internet. Therefore, you would need to either use port forwarding or a LXD proxy device in order to make certbot's temporary Web server accessible from the Internet.
They all look OK.
Let’s verify that they are OK as well.
First, run on the host
sudo tcpdump -nl -i eth0 port 8888
and on your computer make a connection to the host on port 8888. For example,
telnet 23.239.31.177 8888
If the tcpdump command shows activity and packets, then all is fine for the connection towards the host. Obviously, there is no service listening to port 8888, and the connection will terminate.
Repeat by running the tcpdump line in the proxy container. And again, for your computer run the telnet command.
You should be able to see again packets being received.
If everything went well, then you are at the point able to run the certbot command with the standalonehttp-01 challenge. Run the command and show both the command and any output.
To fix these errors, please make sure that your domain name was
entered correctly and the DNS A/AAAA record(s) for that domain
contain(s) the right IP address. Additionally, please check that
your computer has a publicly routable IP address and that no
firewalls are preventing the server from communicating with the
client. If you’re using the webroot plugin, you should also verify
that you are serving files from the webroot path you provided.
According to https://github.com/certbot/certbot/issues/2697 Let’s Encrypt will connect to your server to port 80 to perform the challenge. The --http-01-port is only used on the client side.
Therefore, for the duration of running certbot, you can stop haproxy so that certbot can bind to port 80 in the container and do the challenge successfully. Then, start haproxy.
So I stopped the haproxy service in the container and re-ran cerbot but I am still getting the same error?
I am running certbot inside the haproxy container…right?