I'm attempting to deploy a global unit in CoreOS and it's not working. Here's the unit I'm running the test with
[Unit]
Description=Global Test
[Service]
ExecStart=/usr/bin/true
[X-Fleet]
Global=true
When I do
fleetctl start global.service
fleetctl list-units
I only see one copy of my service running in a cluster with 3 nodes.
410.2.0 does not support global units.
435.0.0 instead shipped fleet 0.8.0 that introduced global units.
See
https://coreos.com/releases/
https://github.com/coreos/fleet/releases/tag/v0.8.0
Just upgrade to coreos 435.0.0 and everything will work as expected.
Related
I am trying to setup a custom systemd service on my linux system and was experimenting with it
Following is my custom service, where it will trigger a bash file
[Unit]
Description=Example systemd service.
After=nginx.service
[Service]
Type=simple
ExecStart=/bin/bash /usr/bin/test_service.sh
[Install]
WantedBy=multi-user.target
Since I have mentioned After=nginx.service i was expecting nginx serivce to start automatically
So after starting the above service, i check the status of nginx, which has not started
However if i replace After with Wants it works
Can someone differenciate between After and Wants and when to use what?
Specifying After=foo tells systemd how to order the units if they are both started at the same time. It will not cause the foo unit to autostart.
Use After=foo in combination with Wants=foo or Requires=foo to start foo if it's not already started and also to keep desired order of the units.
So your [Unit] should include:
[Unit]
Description=Example systemd service.
After=nginx.service
Wants=nginx.service
Difference between Wants and Requires:
Wants= : This directive is similar to Requires= , but less strict. Systemd will attempt to start any units listed here when this unit is activated. If these units are not found or fail to start, the current unit will continue to function. This is the recommended way to configure most dependency relationships.
All my unix host use the ldap backend.
docker group is existing on the ldap, this is also why docker.service must start after nslcd.service.
I have tried to edit systemctl startup configuration for docker.service:
$ sudo systemctl edit --full docker.service
And I add nslcd.service to After, Wants, Requires:
[Unit]
Description=Docker Application Container Engine
Documentation=https://docs.docker.com
After=network-online.target docker.socket firewalld.service nslcd.service
Wants=network-online.target nslcd.service
Requires=docker.socket nslcd.service
I still can't get docker to run after that service:
sudo service docker status
● docker.service - Docker Application Container Engine
Loaded: loaded (/etc/systemd/system/docker.service; enabled; vendor preset: enabled)
Active: inactive (dead)
Docs: https://docs.docker.com
Oct 10 19:35:02 dev-08 systemd[1]: Dependency failed for Docker Application Container Engine.
There is no problem to start container manually after starts, since I login through ldap.
docker group is existing on the ldap, this is also why docker.service must start after nslcd.service.
It is generally a bad idea to have system services depend on users and groups in a remote directory service (because problems with the directory service can impact service availability on your host).
And I add nslcd.service to After, Wants, Requires
Specifying both a Wants= and a Requires= relationship is redundant. The Requires= relationship is simply a stronger version of Wants=: using Requires= means that if you start the docker service, and nslcd is not already running, it will be started as well. Using Wants= in the same situation, docker would start without starting nslcd.
I still can't get docker to run after that service
Is is entirely likely that nslcd takes a moment to connect to the directory service. In this case, it's possible that the process has started, which satisfies the After= dependency, so docker starts even though your groups are not yet available.
There are a few ways of addressing this situation:
In light of my initial comment, just create a local docker group. This is by far the simplest and most robust solution.
Create a new oneshot unit that spins until the docker group exists. Make this unit depend on nslcd, and make docker depend on the new unit.
Possibly replacing nslcd with something that implements local caching (e.g., sssd) would also resolve this problem.
On a different note, it is a bad idea to directly edit the unit files as you have done in this example, because if you've installed Docker via packaging tools (apt/yum/etc), your modifications will be overwritten next time you upgrade the package. A better solution is to create drop-in files to augment the unit configuration.
Update
Option 2 might look like this:
[Unit]
Requires=nslcd.service docker.service
After=nslcd.service
Before=docker.service
[Service]
Type=oneshot
ExecStart=/bin/sh -c "while ! getent group docker; do sleep 1; done"
When publishing .NET Core application on Ubuntu 16.04 I need a way to run the app as a service so that it can be easily managed and automatically restarted if it fails. There is a great guide on how to do this at Microsoft's official docs website. The recommended way is to use the using the systemd command which I have successfully used many times. However I decided to host my .NET Core projects on AWS and decided to use Amazon's Linux distribution which is based on RedHat and it does not have the systemd command. Here is how I created the service configuration previously on the Ubuntu servers.
Basically I am asking for an equivalent way of setting up my .NET Core app as a service and equivalent commands for managing it (start, restart, stop)
[Unit]
Description=Example .NET Web API Application running on Ubuntu
[Service]
WorkingDirectory=/var/aspnetcore/hellomvc
ExecStart=/usr/bin/dotnet /var/aspnetcore/hellomvc/hellomvc.dll
Restart=always
RestartSec=10 # Restart service after 10 seconds if dotnet service crashes
SyslogIdentifier=dotnet-example
User=www-data
Environment=ASPNETCORE_ENVIRONMENT=Production
[Install]
WantedBy=multi-user.target
EDIT: From the comments I have realized that what I am looking for is called a init system. I googled "Linux Amazon init" and found that the default init system used in Linux Amazon is "upstart". Here is the source where I found the answer in the aws forum
I've played around with Panamax as a solution for managing groups of containers on a single server CoreOS installation, but it lacks several features, notably fleet management and user based access restriction.
Finally, the project does not seem to be maintained anymore.
Are there any active and production ready alternatives that make the management of multiple CoreOS servers possible via a UI (Web or desktop)?
Have not yet tried this yet, but Mist.io seems like a very promising option. Comes in both an open source and SaaS version. Open Source version is being actively maintained and their service is production ready for an impressive list of cloud providers. The UI gives options for managing and monitoring CoreOS clusters at both the OS and container levels: you can spin up new hosts and new containers from the same UI. Might be what you are looking for.
The container manager for fleet is fleet-browser:
https://github.com/cloudwalkio/fleet-browser
Here is the unit file I use to deploy it, just change the lines where I have put "YOURBLAH", etc.
[Unit]
Description=Expose Fleet API in a nice GUI
Requires=docker.service
After=docker.service
[Service]
EnvironmentFile=/etc/environment
KillMode=none
TimeoutStartSec=0
Restart=always
RestartSec=10s
ExecStartPre=-/usr/bin/docker kill fleet-browser
ExecStartPre=-/usr/bin/docker rm fleet-browser
ExecStartPre=/usr/bin/docker pull cloudwalk/fleet-browser:latest
ExecStart=/usr/bin/docker run --net=host --rm --name fleet-browser \
-e FLEET_ENDPOINT=YOURENDPOINT:8081 \
-e ETCD_ENDPOINT=YOURENDPOINT:2379 \
-p 5000:5000 cloudwalk/fleet-browser:latest
ExecStop=/usr/bin/docker stop fleet-browser
[X-Fleet]
MachineMetadata="server-type=YOURSERVERTYPE" "node=YOURNODENAME"
I have a coreOS cluster with 3 instances. I need to init a service in the 3 instances, but I don't want to use the IP to connect. Is there a dynamic way to scan the instances and get the IP's and then use it?
You can use the following command to get a list of the cluster instances for further processing:
fleetctl list-machines | awk '{print $2}' | tail -n +2
If you want to use the IP in one of your containers/services, and you're running CoreOS on a cloud providers, you can source in an environment file with the allocated IPs:
[Service]
EnvironmentFile=/etc/environment
and then use those values as environment variables.
CoreOS has a built in scheduler called fleet that runs on all hosts. You can just create the service and execute the command to run the service:
fleetctl start myunit.service.
To tail the output of the service you can run: fleetctl journal -f myunit.service which will automatically ssh into the host running the container, and see the output.
"I need to init a service in the 3 instances"
It seems like you're trying to run a service that should be active on all hosts in the CoreOS cluster. Take a look at the X-Fleet variable Global. You can set up a service to run on all hosts by adding this to the bottom of your service/unit file:
[X-Fleet]
Global=true
This way you will only have to start the service once, to initiate it on all hosts in the CoreOS cluster.