-
Notifications
You must be signed in to change notification settings - Fork 0
/
index.xml
231 lines (190 loc) · 14.1 KB
/
index.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
<title>immortal</title>
<link>https://immortal.run/</link>
<description>Recent content on immortal</description>
<generator>Hugo -- gohugo.io</generator>
<language>en-us</language>
<lastBuildDate>Thu, 20 Apr 2017 16:23:13 +0200</lastBuildDate>
<atom:link href="https://immortal.run/index.xml" rel="self" type="application/rss+xml" />
<item>
<title>openbsd port</title>
<link>https://immortal.run/openbsd/</link>
<pubDate>Thu, 20 Apr 2017 16:23:13 +0200</pubDate>
<guid>https://immortal.run/openbsd/</guid>
<description>To install immortal on OpenBSD &gt;= 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:</description>
</item>
<item>
<title>How it works</title>
<link>https://immortal.run/post/how-it-works/</link>
<pubDate>Tue, 21 Mar 2017 12:04:36 +0100</pubDate>
<guid>https://immortal.run/post/how-it-works/</guid>
<description>⭕ 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 &ldquo;immortal.sock&rdquo; (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 *.</description>
</item>
<item>
<title>compile from source</title>
<link>https://immortal.run/linux/</link>
<pubDate>Mon, 20 Mar 2017 16:17:00 +0000</pubDate>
<guid>https://immortal.run/linux/</guid>
<description>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 &gt;= 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:</description>
</item>
<item>
<title>compile from source</title>
<link>https://immortal.run/source/</link>
<pubDate>Mon, 20 Mar 2017 16:17:00 +0000</pubDate>
<guid>https://immortal.run/source/</guid>
<description>Compile from source Setup go environment https://golang.org/doc/install
go &gt;= 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.</description>
</item>
<item>
<title>pkg install immortal</title>
<link>https://immortal.run/freebsd/</link>
<pubDate>Mon, 20 Mar 2017 16:17:00 +0000</pubDate>
<guid>https://immortal.run/freebsd/</guid>
<description>To install immortal on FreeBSD:
$ pkg install immortal https://www.freshports.org/sysutils/immortal</description>
</item>
<item>
<title>homebrew</title>
<link>https://immortal.run/mac/</link>
<pubDate>Thu, 16 Mar 2017 22:54:37 +0100</pubDate>
<guid>https://immortal.run/mac/</guid>
<description>To install immortal on Mac OS X:
$ brew install immortal </description>
</item>
<item>
<title>The problem to solve</title>
<link>https://immortal.run/post/the-problem-to-solve/</link>
<pubDate>Wed, 20 Jul 2016 21:07:15 +0200</pubDate>
<guid>https://immortal.run/post/the-problem-to-solve/</guid>
<description>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.</description>
</item>
<item>
<title>⭕ immortal</title>
<link>https://immortal.run/about/</link>
<pubDate>Wed, 20 Jul 2016 17:34:22 +0200</pubDate>
<guid>https://immortal.run/about/</guid>
<description>What is immortal ? A *nix cross-platform (OS agnostic) supervisor based on daemontools &amp; runit.
Improve the wheel, don’t reinvent it
Why another supervisor ? Daemontools &amp; runit work very well but don&rsquo;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:</description>
</item>
<item>
<title>run.yml</title>
<link>https://immortal.run/post/run.yml/</link>
<pubDate>Wed, 06 Jul 2016 20:35:39 +0200</pubDate>
<guid>https://immortal.run/post/run.yml/</guid>
<description>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.</description>
</item>
<item>
<title>retries</title>
<link>https://immortal.run/post/retries/</link>
<pubDate>Wed, 06 Jul 2016 20:34:39 +0200</pubDate>
<guid>https://immortal.run/post/retries/</guid>
<description>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 &lt;src&gt; user@host:/&lt;dest&gt; 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.</description>
</item>
<item>
<title>stderr</title>
<link>https://immortal.run/post/stderr/</link>
<pubDate>Wed, 06 Jul 2016 20:35:39 +0201</pubDate>
<guid>https://immortal.run/post/stderr/</guid>
<description>STDOUT &amp; 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.</description>
</item>
<item>
<title>Using Nginx</title>
<link>https://immortal.run/post/nginx/</link>
<pubDate>Fri, 26 Mar 2010 23:14:08 +0200</pubDate>
<guid>https://immortal.run/post/nginx/</guid>
<description>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/&lt;service name&gt;/immortal.sock To check the service status:</description>
</item>
<item>
<title>Ansible</title>
<link>https://immortal.run/post/ansible/</link>
<pubDate>Fri, 26 Mar 2010 23:10:08 +0200</pubDate>
<guid>https://immortal.run/post/ansible/</guid>
<description>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: &quot;{{ ansible_date_time.iso8601 }}&quot; - name: create arena release dir file: path=/arena/foo/releases/{{ now }} state=directory - name: download app.bz2 get_url: url: &quot;http://domain.tld/foo/{{ 'freebsd' if ansible_os_family == 'FreeBSD' else 'linux' }}/app.tar.bz2&quot; dest: /arena/foo/releases/{{ now }} - name: unarchive app.</description>
</item>
<item>
<title>immortal</title>
<link>https://immortal.run/post/immortal/</link>
<pubDate>Thu, 25 Mar 2010 23:34:54 +0200</pubDate>
<guid>https://immortal.run/post/immortal/</guid>
<description>⭕ 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 &ldquo;immortal.sock&rdquo;, 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 &lt;dir&gt; before starting the command</description>
</item>
<item>
<title>immortalctl</title>
<link>https://immortal.run/post/immortalctl/</link>
<pubDate>Wed, 24 Mar 2010 23:34:54 +0200</pubDate>
<guid>https://immortal.run/post/immortalctl/</guid>
<description>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:</description>
</item>
<item>
<title>immortaldir</title>
<link>https://immortal.run/post/immortaldir/</link>
<pubDate>Tue, 23 Mar 2010 23:34:54 +0200</pubDate>
<guid>https://immortal.run/post/immortaldir/</guid>
<description>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 &amp; stop.
If a file is touched and service is down, it will be started, immortalctl start.</description>
</item>
<item>
<title>How to install & setup</title>
<link>https://immortal.run/post/how-to-install/</link>
<pubDate>Mon, 22 Mar 2010 23:34:54 +0200</pubDate>
<guid>https://immortal.run/post/how-to-install/</guid>
<description>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.</description>
</item>
<item>
<title>Systemd</title>
<link>https://immortal.run/post/systemd/</link>
<pubDate>Sun, 21 Mar 2010 23:10:07 +0200</pubDate>
<guid>https://immortal.run/post/systemd/</guid>
<description>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&gt;&amp;1 | logger -t immortaldir KillMode=process Restart=always Restart=on-failure Type=simple User=root [Install] WantedBy=multi-user.target </description>
</item>
<item>
<title>Examples</title>
<link>https://immortal.run/post/examples/</link>
<pubDate>Sat, 20 Mar 2010 23:10:07 +0200</pubDate>
<guid>https://immortal.run/post/examples/</guid>
<description>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, &ldquo;run something forever&rdquo; 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.</description>
</item>
</channel>
</rss>