Openshift V3 offers a simple solution to call external services.
This solution lacks some possibilities like use DNS names or use more then one destination.
The here described solution offers you the flexibility of haproxy with logs for this service.
Here the picture for the solution.
- Openshift v3
- Your own git repository
- HAProxy 1.6
- socklog / syslog
- destination address(s)
Openshift v3 and git repository
You need access to a openshift (oc …/ webconsole) and a read / write access to a git repository
You can use the official image on Docker Hub HAProxy, but I would suggest to use the alpine image. I also used it for a small http-https redirector which you can find here. An example with log settings you may find here
socklog / syslog
Due to the fact that there is no official Docker Hub entry for socklog you can use my repo
You´ll have to chose the service you want to connect
Now you should take a look into the excellence documentation of HAProxy.
Start of Implementation
Create a new Project
oc new-project external-service001
otherwise, if you are admin and want to run this pods on dedicated nodes you can also use
oadm new-project external-service001 --node-selector='your-dmz=external-router'
oc new-app-e TZ=Europe/Vienna --dry-run -o yaml > 01_build_socklog.yaml oc create -f 01_build_socklog.yaml
imagestream "alpine" created imagestream "alpine-socklog" created buildconfig "alpine-socklog" created deploymentconfig "alpine-socklog" created service "alpine-socklog" created
Q: Why do I create a file instead of a direct output?
A: For reproduction and debugging. It’s easier do run an oc delete -f 01_build_socklog.yaml😉
Finally a alpine-socklog service with exposed port 8514/udp is created
oc get svc NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE alpine-socklog 172.30.189.182 <none> 8514/UDP 3m
also a listening daemon which writes the requests out to stdout
oc logs -f alpine-socklog-1-mldc6 listening on 0.0.0.0:8514, starting.
Don’t use the user/uid and group/gid on Openshift!
Dont’t use daemon option in Openshift!
Due to the fact that you have to change the HAProxy config, you´ll need a Git repository.
I use mine😉
Now you ´ll have to edit the containerfiles/etc/haproxy/haproxy.cfg and add the log option.
Commit it to your repo and create the app
oc new-app-e TZ=Europe/Vienna --dry-run -o yaml > metadata/01_build_haproxy.yaml oc create -f metadata/01_build_haproxy.yaml
imagestream "http-https-redirector" created buildconfig "http-https-redirector" created deploymentconfig "http-https-redirector" created service "http-https-redirector" created Error from server: imageStream "alpine" already exists
Within a few minutes the pods are up and running
oc get po NAME READY STATUS RESTARTS AGE alpine-socklog-1-build 0/1 Completed 0 10h alpine-socklog-1-mldc6 1/1 Running 0 10h http-https-redirector-1-build 0/1 Completed 0 4m http-https-redirector-2-build 0/1 Completed 0 1m http-https-redirector-2-k56kr 1/1 Running 0 35s
in the log of alpine-socklog-1-mldc6 pod you can find the log-entries of HAProxy.
[al@localhost openshift-external-services]$ oc logs -f alpine-socklog-1-mldc6 listening on 0.0.0.0:8514, starting. 10.1.3.1: local0.notice: Apr 27 18:29:18 haproxy: Proxy entry-point started. 10.1.3.1: local0.notice: Apr 27 18:29:18 haproxy: Proxy google started.
Finally we should add a route to use this service.
oc expose svc http-https-redirector
If everything works as expect you should see something like this.
10.1.5.1: local0.notice: Apr 27 19:56:25 haproxy: Proxy entry-point started. 10.1.5.1: local0.notice: Apr 27 19:56:25 haproxy: Proxy be_google started. 10.1.5.1: local0.info: Apr 27 19:56:55 haproxy: 10.1.2.1:41173 [27/Apr/2016:19:56:55.189] entry-point be_google/srv_google/220.127.116.11 0/0/111/18/129 404 1686 - - ---- 1/1/0/1/0 0/0 "GET / HTTP/1.1" 10.1.5.1: local0.info: Apr 27 19:57:21 haproxy: 10.1.2.1:41427 [27/Apr/2016:19:57:21.555] entry-point be_google/srv_google/18.104.22.168 0/0/42/18/60 404 1686 - - ---- 1/1/0/1/0 0/0 "GET / HTTP/1.1"
After all these steps, you have to use the documentation of HAProxy and alpine to fix the time and the ip issue unless you don’t need to know which client have requested your service😉
You may also get in touch with us (Cloudwerkstatt) to fix it for you.