Update the server. I just did a yum update from commandline. It brings the server up to date with the latest patches
(if this isn’t the NethServer way, slap me, I am new to using the server)
Now let’s take it 1 step further and install Wordpress on NethServer:
Log into cockpit with a (domain) admin account.
When you are logged incockpit you see the system overview with some tickers:
Select the Wordpress image you want to use.
After downloading the docker image, start the image by clicking the “play” triangle on the right.
A popup appears with all the preset options of the image
As you can see, automaticly a name for your WP container is created. You can tweak the other settings if you like. If you need more memory, you can override the default by ticking the box in front of memory limit.
If you want to change ports, you can do that here too.
Finally, click the blue RUN button.
I was still struggling with docker images using port 80 and the NS startpage is running on 80 and 443 too. Probably need to change something on those. A comment on that is appreciated.
We cannot mask a root path, like http://mysite/ and pass it to our docker container or whatever else.
On the firewall side, our latest Shorewall should come with improved Docker support and I hope this will help us a lot. But if we talk about ports 80 and 443, the httpd reverse proxy is the mandatory choice to keep the all-in-one design.
I also installed cockpit on my laptop running ubuntu 16.04
Here I have absolutely no problems because each container gets it’s own IP address in another subnet that is somehow bridged to the cockpit instance on my laptop.
My local IP subnet is 192.168.10.1/24 and the ip addresses for each container are in the 172.17.0.1/24 subnet.
Well that went smooth! How easy can it be.,… LOL… at least it kept me busy this evening…
Still it amazes me how easy and fast a service can be up and running if you can pick an image from cockpit repository.
Now digging into creating Docker images from scratch, but that is for another time…
There are still some challenges. For instance a web app may require a DB, or access to LDAP. Additional containers could come into play, or access to services running on the host machine could be required.
How to configure them during the beloved point&click installation?
That’s what I meant with how it runs on my Ubuntu laptop: Cockpit is being used as a bridge between the docker containers and the rest of the world. Each container gets it’s own IP address.
This is cockpit from my laptop: reachable on localhost:9090
On the “containers” page I have 1 image available from the cockpit repository: nextcloud.
When I start that image a container is created with the following properties:
This method of giving each container an IP address in a separate subnet would solve the port problem. I don’t know yet if the docker images will be available from another machine or even externally.
So if I understand this correctly the host is being a router here. And Docker created a virtual interface called dockerx. During install the routes were already created but if you want to reach the docker containers, you must add DNS entries and open ports on your host so the outside world can find and reach the container?
Is it this DNS option that is currently lacking in NS? If the Docker containers only need to be available for the Domain clients, then adding entries in DNS pointing to the host should be enough?
Again, do you have any idea why the Ubuntu version of Cockpit/Docker uses an unique IP for each container in another subnet and on CentOS7(nethserver7b2) this is not the case?
If NethServer is acting as DNS on the LAN network this would help. As said above, for web app containers we need to configure the httpd reverse proxy, too.
This sounds strange for me. Maybe I’m wrong, but I was sure on CentOS7 it works the same: each container is assigned an IP from the default docker internal network…
unfortunately cockpit’s concept is “against” distro like NS, meaning that cockpit just reflects and configure underlying system via dbus and so on…
I had a chat with Stef (cockpit’s creator) some time ago… he said that if I want to create an alternative to NS webgui (or SME’s server-manager) cockpit is not the kind of product I need, because there’s no way to insert a “logical layer” (the e-smith one) between the GUI and the O.S…
this will work only if:
you rewrite a big part of the code (and I’m not referrig to the web part, which is quite complex but workable, but to the bridge/ws side, which are in c)
you use cockpit only as a part of your project, writing your own modules
in any case, ATM, there’s no idea (on cockpit side) to create a user delegation module, meaning that all the users that can auth via console can access cockpit… it’s true that then an non privileged user can edit/modify only parts on which he has privileges, but he can still see almost everything (all users ecc)
there are some workarounds (sudoers, use of local links ecc) but, for example, there’s no way to let a single user to see his account only to change his password.
finally, even if creation of custom modules is quite easy (I did it on SME) using the cockpit.spawn method, the right/secure way is to create a custom web service listening on localhost which get data from the GUI and executes some kind of logic
Thanks you for your input @Stefano_Zamboni
I do see your reasoning, but isn’t it so that each docker container is given a seperate IP address? So each available service will be available separated from others. If you use cockpit/docker just as a gateway between your userLAN and the services, there is no need anyone has access to something like the cockpit interface, except (domain) admins.
I am still trying to get to know the basics, but I don’t see why adding a dockerized service would be a security thread. The service is running on a separate network and you have NethServer in between.
What should be identified apart from docker security aspects?
my reasoning isn’t related to docker in any way… maybe this is the wrong 3ad, but the idea to use cockpit as a new NS webgui has the problems I told above… sorry for the misunderstanding
Then if docker isn’t the problem, why should cockpit be? Cockpit is just a nice webgui for docker (plus a management console for the server running docker).
Maybe I am too ignorant here since I still have no clue what the e-smith template layer actually does. I will have to dive into that to fully understand I guess.
I’m sorry but you’re wrong
Docker is just a module, an applet in cockpit
Defining cockpit as you did it above means that you’d read carefully the “concepts behind cockpit”
Sometime, I’m like Stefano about Docker;
I’m not always sure this is a good thing;
and also attribute that at i’m too old for new stuff
So, I’m going deeper into to learn and understand the beast …
One good thing about Cockpit I could say it’s using devicemapper
which is mostly the only Storage type could be considered Production Ready
It’s also develop by RedHat
