https://immortal.run/ Recent content on immortal Hugo -- gohugo.io en-us Thu, 20 Apr 2017 16:23:13 +0200 https://immortal.run/openbsd/ Thu, 20 Apr 2017 16:23:13 +0200 https://immortal.run/openbsd/ To install immortal on OpenBSD >= 6.1 you can use this port: https://github.com/immortal/immortal.vendor/releases/download/0.13.2/immortal.tar.gz Or compile from source: https://immortal.run/post/how-it-works/ Tue, 21 Mar 2017 12:04:36 +0100 https://immortal.run/post/how-it-works/ ⭕ immortal runs a command or script detached from the controlling terminal as a Unix daemon, it will supervise and restart the service if it has been terminated. The service can be controlled by querying a Unix socket “immortal.sock” (immortalctl), this allows to remotely have full control over the service if required by exposing the socket using a web server like Nginx. immortal - Starts and monitor a service immortaldir - Directory to scan for services *. https://immortal.run/linux/ Mon, 20 Mar 2017 16:17:00 +0000 https://immortal.run/linux/ pre-compiled (Linux) Using https://packagecloud.io/immortal/immortal For deb: curl -s https://packagecloud.io/install/repositories/immortal/immortal/script.deb.sh | sudo bash Then: apt install immortal For rpm: curl -s https://packagecloud.io/install/repositories/immortal/immortal/script.rpm.sh | sudo bash Then: yum install immortal Compile from source Setup go environment https://golang.org/doc/install go >= 1.9 is required For example using $HOME/go for your workspace $ export GOPATH=$HOME/go Create the directory: $ mkdir -p $HOME/go/src/github.com/immortal Clone project into that directory: https://immortal.run/source/ Mon, 20 Mar 2017 16:17:00 +0000 https://immortal.run/source/ Compile from source Setup go environment https://golang.org/doc/install go >= 1.9 is required For example using $HOME/go for your workspace $ export GOPATH=$HOME/go Create the directory: $ mkdir -p $HOME/go/src/github.com/immortal Clone project into that directory: $ git clone [email protected]:immortal/immortal.git $HOME/go/src/github.com/immortal/immortal Build by just typing make: $ cd $HOME/go/src/github.com/immortal/immortal $ make To install/uninstall: $ make install $ make uninstall Help making the port/package If you are familiar with the platform, would be nice if could create a native port in order make more simple the installation process. https://immortal.run/freebsd/ Mon, 20 Mar 2017 16:17:00 +0000 https://immortal.run/freebsd/ To install immortal on FreeBSD: $ pkg install immortal https://www.freshports.org/sysutils/immortal https://immortal.run/mac/ Thu, 16 Mar 2017 22:54:37 +0100 https://immortal.run/mac/ To install immortal on Mac OS X: $ brew install immortal https://immortal.run/post/the-problem-to-solve/ Wed, 20 Jul 2016 21:07:15 +0200 https://immortal.run/post/the-problem-to-solve/ A common way to start up services Either you are using macOs, FreeBSD, or any Linux variant the idea is to simplify how process/services are keep up and running, without need to worry about special environments or paths. A single run.yml file should be enough for start and supervise the services, or used as a template within automation tools like Saltstack, Ansible, etc. Follow PID In some cases it is required to supervise applications that daemonize by default. https://immortal.run/about/ Wed, 20 Jul 2016 17:34:22 +0200 https://immortal.run/about/ What is immortal ? A *nix cross-platform (OS agnostic) supervisor based on daemontools & runit. Improve the wheel, don’t reinvent it Why another supervisor ? Daemontools & runit work very well but don’t cover all use cases, mainly when dealing with applications that follow the zero-downtime deployment pattern (unicorn/gunicorn), applications that daemonize itself like nginx or when distributed logging is required. Example of a zero-downtime flow using unicorn and signal handling: https://immortal.run/post/run.yml/ Wed, 06 Jul 2016 20:35:39 +0200 https://immortal.run/post/run.yml/ immortal -c run.yml A configuration file for running/logging/supervising: cmd: bundle exec unicorn -c unicorn.rb cwd: /arena/app-1 env: DEBUG: 1 ENVIRONMENT: production pid: follow: /arena/app-1/unicorn.pid parent: /arena/app-1/parent.pid child: /arena/app-1/child.pid log: file: /var/log/app-1.log age: 86400 # seconds num: 7 # int size: 1 # MegaBytes timestamp: true # will add timesamp to log logger: logger -t unicorn user: www wait: 1 require: - foo - bar One of the main ideas behind the run. https://immortal.run/post/retries/ Wed, 06 Jul 2016 20:34:39 +0200 https://immortal.run/post/retries/ In some cases, you may not want to run a command forever, here is where the option -r / retries becomes useful. This option normally is only used directly from the command line, for example: immortal -w 60 -r 3 rsync -aHAXxv --numeric-ids --delete -P <src> user@host:/<dest> In this case immortal will wait -w 60 seconds before starting and it will only try to run the command for 3 times after that it will exit. https://immortal.run/post/stderr/ Wed, 06 Jul 2016 20:35:39 +0201 https://immortal.run/post/stderr/ STDOUT & STDERR By just using the option log the output file combine the standard output and the standard error, in case a file is required per each output the stderr could be used, for example: cmd: command log: file: /var/log/app.log age: 86400 # seconds num: 7 # int size: 1 # MegaBytes stderr: file: /var/log/app-error.log age: 86400 # seconds num: 7 # int size: 1 # MegaBytes timestamp: true # will add timesamp to log In this case only the STDOUT will be written to /varlog/app. https://immortal.run/post/nginx/ Fri, 26 Mar 2010 23:14:08 +0200 https://immortal.run/post/nginx/ To expose the services via web Nginx can be used. Configuration example: upstream immortal { server unix:/var/run/immortal/sleep/immortal.sock; } server { listen 80 default_server; server_name _; location / { proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $http_host; proxy_set_header X-NginX-Proxy true; proxy_http_version 1.1; # for keep-alive proxy_pass http://immortal/; proxy_redirect off; } } Based on the setup, permissions for the socket may need to be changed: $ chmod 766 /var/run/immortal/<service name>/immortal.sock To check the service status: https://immortal.run/post/ansible/ Fri, 26 Mar 2010 23:10:08 +0200 https://immortal.run/post/ansible/ Example of a basic ansible playbook for deploying a micro service using a configuration file: - hosts: your-host become: true tasks: - name: create arena file: path=/arena/foo/releases state=directory - name: set now variable set_fact: now: "{{ ansible_date_time.iso8601 }}" - name: create arena release dir file: path=/arena/foo/releases/{{ now }} state=directory - name: download app.bz2 get_url: url: "http://domain.tld/foo/{{ 'freebsd' if ansible_os_family == 'FreeBSD' else 'linux' }}/app.tar.bz2" dest: /arena/foo/releases/{{ now }} - name: unarchive app. https://immortal.run/post/immortal/ Thu, 25 Mar 2010 23:34:54 +0200 https://immortal.run/post/immortal/ ⭕ immortal runs a command or script detached from the controlling terminal as a Unix daemon, it will supervise and restart the service if it has been terminated. The service can be controlled by querying a Unix socket “immortal.sock”, this allows to remotely have full control over the service if required by exposing the socket using a web server like Nginx. immortal [-v] [-ctl dir] [-d dir] [-e dir] [-f pidfile] [-l logfile] [-logger logger] [-p child_pidfile] [-P supervisor_pidfile] [-u user] command -d dir Change to directory <dir> before starting the command https://immortal.run/post/immortalctl/ Wed, 24 Mar 2010 23:34:54 +0200 https://immortal.run/post/immortalctl/ immortalctl control services started by immortal immortalctl [options] [-12achikinouqstvw] [*|service] immortalctl by default prints the status of any available processes started by immortal, it first searches for user process located in $HOME/.immortal and next on the system global services started by immortaldir located by default in /var/run/immortal unless this has been changed by defining the environment var IMMORTAL_SDIR. When no services found the output will be a single row only with the headers: https://immortal.run/post/immortaldir/ Tue, 23 Mar 2010 23:34:54 +0200 https://immortal.run/post/immortaldir/ immortaldir start services located in a specified directory. immortalctl [dir] [-v] immortaldir will watch for changes in the specified directory kqueue(2), if using Linux, will scan the directory every 5 seconds searching for files ending in .yml and track changes. The files should conform the immortal configuration format. If a file changes the service will be restarted, immortalctl exit & stop. If a file is touched and service is down, it will be started, immortalctl start. https://immortal.run/post/how-to-install/ Mon, 22 Mar 2010 23:34:54 +0200 https://immortal.run/post/how-to-install/ At the moment of writing this document currently immortal can be installed in macOS via homebrew and FreeBSD (ports/pkg), therefore if you are familiar with your current operating system would be nice if you could contribute by creating a native port in order to make more simple the installation process. Installing on Linux The easy way so far is to install a pre-compiled release, download the latest one that matches your architecture. https://immortal.run/post/systemd/ Sun, 21 Mar 2010 23:10:07 +0200 https://immortal.run/post/systemd/ To start immortaldir on Linux with systemd, put this script in /etc/systemd/system/immortaldir.service: [Unit] Description=immortaldir After=network.target [Service] ExecStart=/usr/bin/immortaldir /etc/immortal 2>&1 | logger -t immortaldir KillMode=process Restart=always Restart=on-failure Type=simple User=root [Install] WantedBy=multi-user.target https://immortal.run/post/examples/ Sat, 20 Mar 2010 23:10:07 +0200 https://immortal.run/post/examples/ The main idea behind immortal is to keep up and running services forever even if the server is rebooted the service should be started and based on the requirements probably the services may start in sequence by waiting for others to start, wait some seconds before starting, etc, but at the end the idea remains, “run something forever” and in case exist just restart it. Doing this could be tricky, mainly because if you just want to launch your service/worker/daemon, etc you may not want to spend to much time understanding how to properly launch something in the operating system your company is using.