Skip to content

Commit b34a90b

Browse files
naparubanaparuba
committed
Enh: more tests about Alpine linux
1 parent 55d2098 commit b34a90b

File tree

139 files changed

+21147
-5
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

139 files changed

+21147
-5
lines changed

‎doc/LICENSE

+354
Large diffs are not rendered by default.

‎doc/Makefile

+108
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,108 @@
1+
PY=python
2+
PELICAN=pelican
3+
PELICANOPTS=
4+
5+
BASEDIR=$(CURDIR)
6+
INPUTDIR=$(BASEDIR)/content
7+
OUTPUTDIR=$(BASEDIR)/output
8+
CONFFILE=$(BASEDIR)/pelicanconf.py
9+
PUBLISHCONF=$(BASEDIR)/publishconf.py
10+
11+
FTP_HOST=localhost
12+
FTP_USER=anonymous
13+
FTP_TARGET_DIR=/
14+
15+
SSH_HOST=localhost
16+
SSH_PORT=22
17+
SSH_USER=root
18+
SSH_TARGET_DIR=/var/www
19+
20+
S3_BUCKET=my_s3_bucket
21+
22+
CLOUDFILES_USERNAME=my_rackspace_username
23+
CLOUDFILES_API_KEY=my_rackspace_api_key
24+
CLOUDFILES_CONTAINER=my_cloudfiles_container
25+
26+
DROPBOX_DIR=~/Dropbox/Public/
27+
28+
DEBUG ?= 0
29+
ifeq ($(DEBUG), 1)
30+
PELICANOPTS += -D
31+
endif
32+
33+
help:
34+
@echo 'Makefile for a pelican Web site '
35+
@echo ' '
36+
@echo 'Usage: '
37+
@echo ' make html (re)generate the web site '
38+
@echo ' make clean remove the generated files '
39+
@echo ' make regenerate regenerate files upon modification '
40+
@echo ' make publish generate using production settings '
41+
@echo ' make serve [PORT=8000] serve site at http://localhost:8000'
42+
@echo ' make devserver [PORT=8000] start/restart develop_server.sh '
43+
@echo ' make stopserver stop local server '
44+
@echo ' make ssh_upload upload the web site via SSH '
45+
@echo ' make rsync_upload upload the web site via rsync+ssh '
46+
@echo ' make dropbox_upload upload the web site via Dropbox '
47+
@echo ' make ftp_upload upload the web site via FTP '
48+
@echo ' make s3_upload upload the web site via S3 '
49+
@echo ' make cf_upload upload the web site via Cloud Files'
50+
@echo ' make github upload the web site via gh-pages '
51+
@echo ' '
52+
@echo 'Set the DEBUG variable to 1 to enable debugging, e.g. make DEBUG=1 html'
53+
@echo ' '
54+
55+
html:
56+
$(PELICAN) $(INPUTDIR) -o $(OUTPUTDIR) -s $(CONFFILE) $(PELICANOPTS)
57+
58+
clean:
59+
[ ! -d $(OUTPUTDIR) ] || rm -rf $(OUTPUTDIR)
60+
61+
regenerate:
62+
$(PELICAN) -r $(INPUTDIR) -o $(OUTPUTDIR) -s $(CONFFILE) $(PELICANOPTS)
63+
64+
serve:
65+
ifdef PORT
66+
cd $(OUTPUTDIR) && $(PY) -m pelican.server $(PORT)
67+
else
68+
cd $(OUTPUTDIR) && $(PY) -m pelican.server
69+
endif
70+
71+
devserver:
72+
ifdef PORT
73+
$(BASEDIR)/develop_server.sh restart $(PORT)
74+
else
75+
$(BASEDIR)/develop_server.sh restart
76+
endif
77+
78+
stopserver:
79+
kill -9 `cat pelican.pid`
80+
kill -9 `cat srv.pid`
81+
@echo 'Stopped Pelican and SimpleHTTPServer processes running in background.'
82+
83+
publish:
84+
$(PELICAN) $(INPUTDIR) -o $(OUTPUTDIR) -s $(PUBLISHCONF) $(PELICANOPTS)
85+
86+
ssh_upload: publish
87+
scp -P $(SSH_PORT) -r $(OUTPUTDIR)/* $(SSH_USER)@$(SSH_HOST):$(SSH_TARGET_DIR)
88+
89+
rsync_upload: publish
90+
rsync -e "ssh -p $(SSH_PORT)" -P -rvz --delete $(OUTPUTDIR)/ $(SSH_USER)@$(SSH_HOST):$(SSH_TARGET_DIR) --cvs-exclude
91+
92+
dropbox_upload: publish
93+
cp -r $(OUTPUTDIR)/* $(DROPBOX_DIR)
94+
95+
ftp_upload: publish
96+
lftp ftp://$(FTP_USER)@$(FTP_HOST) -e "mirror -R $(OUTPUTDIR) $(FTP_TARGET_DIR) ; quit"
97+
98+
s3_upload: publish
99+
s3cmd sync $(OUTPUTDIR)/ s3://$(S3_BUCKET) --acl-public --delete-removed
100+
101+
cf_upload: publish
102+
cd $(OUTPUTDIR) && swift -v -A https://auth.api.rackspacecloud.com/v1.0 -U $(CLOUDFILES_USERNAME) -K $(CLOUDFILES_API_KEY) upload -c $(CLOUDFILES_CONTAINER) .
103+
104+
github: publish
105+
ghp-import $(OUTPUTDIR)
106+
git push origin gh-pages
107+
108+
.PHONY: html help clean regenerate serve devserver publish ssh_upload rsync_upload dropbox_upload ftp_upload s3_upload cf_upload github

‎doc/README.md

+5
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,5 @@
1+
XXX website and documentation
2+
=============
3+
4+
5+
This repository is both forked from shinkenlab.io repository (MIT) and consul documentation (MPL2) for the content.

‎doc/content/pages/about.md

+11
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,11 @@
1+
Title: About
2+
Slug: about
3+
4+
#About
5+
6+
Hi. This is the main blog of the Shinken framework community. We are mainly devops that want to be sure their productions are running well :) This site serves as a medium for sharing ideas and rendering nerdy thoughts.
7+
8+
<ul>
9+
<li><a href="/">shinkenlab.io</a></li>
10+
<li>[email protected] (I'll redirect to the good mail if need)</li>
11+
</ul>

‎doc/content/pages/docs/agent/basics.md

+95
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,95 @@
1+
Title: Agent
2+
Slug: docs/agent/basics
3+
4+
5+
# XXX Agent
6+
7+
The XXX agent is the core process of XXX. The agent maintains membership
8+
information, registers services, runs checks, responds to queries
9+
and more. The agent must run on every node that is part of a XXX cluster.
10+
11+
Any Agent may run in one of two modes: client or server. A server
12+
node takes on the additional responsibility of being part of the [consensus quorum](#).
13+
These nodes take part in Raft, and provide strong consistency and availability in
14+
the case of failure. The higher burden on the server nodes means that usually they
15+
should be run on dedicated instances, as they are more resource intensive than a client
16+
node. Client nodes make up the majority of the cluster, and they are very lightweight
17+
as they maintain very little state and interface with the server nodes for most operations.
18+
19+
## Running an Agent
20+
21+
The agent is started with the `XXX agent` command. This command blocks,
22+
running forever or until told to quit. The agent command takes a variety
23+
of configuration options but the defaults are usually good enough. When
24+
running `XXX agent`, you should see output similar to that below:
25+
26+
```
27+
$ XXX agent -data-dir=/tmp/XXX
28+
==> Starting XXX agent...
29+
==> Starting XXX agent RPC...
30+
==> XXX agent running!
31+
Node name: 'Armons-MacBook-Air'
32+
Datacenter: 'dc1'
33+
Server: false (bootstrap: false)
34+
Client Addr: 127.0.0.1 (HTTP: 8500, DNS: 8600, RPC: 8400)
35+
Cluster Addr: 192.168.1.43 (LAN: 8301, WAN: 8302)
36+
37+
==> Log data will now stream in as it occurs:
38+
39+
[INFO] serf: EventMemberJoin: Armons-MacBook-Air.local 192.168.1.43
40+
...
41+
```
42+
43+
There are several important components that `XXX agent` outputs:
44+
45+
* **Node name**: This is a unique name for the agent. By default this
46+
is the hostname of the machine, but you may customize it to whatever
47+
you'd like using the `-node` flag.
48+
49+
* **Datacenter**: This is the datacenter the agent is configured to run
50+
in. XXX has first-class support for multiple datacenters, but to work efficiently
51+
each node must be configured to correctly report its datacenter. The `-dc` flag
52+
can be used to set the datacenter. For single-DC configurations, the agent
53+
will default to "dc1".
54+
55+
* **Server**: This shows if the agent is running in the server or client mode.
56+
Server nodes have the extra burden of participating in the consensus quorum,
57+
storing cluster state, and handling queries. Additionally, a server may be
58+
in "bootstrap" mode. Multiple servers cannot be in bootstrap mode,
59+
otherwise the cluster state will be inconsistent.
60+
61+
* **Client Addr**: This is the address used for client interfaces to the agent.
62+
This includes the ports for the HTTP, DNS, and RPC interfaces. The RPC
63+
address is used for other `XXX` commands. Other XXX commands such
64+
as `XXX members` connect to a running agent and use RPC to query and
65+
control the agent. By default, this binds only to localhost. If you
66+
change this address or port, you'll have to specify an `-rpc-addr` whenever
67+
you run commands such as `XXX members` so they know how to talk to the
68+
agent. This is also the address other applications can use over [RPC to control XXX](/docs/agent/rpc.html).
69+
70+
* **Cluster Addr**: This is the address and ports used for communication between
71+
XXX agents in a cluster. Every XXX agent in a cluster does not have to
72+
use the same port, but this address **MUST** be reachable by all other nodes.
73+
74+
## Stopping an Agent
75+
76+
An agent can be stopped in two ways: gracefully or forcefully. To gracefully
77+
halt an agent, send the process an interrupt signal, which is usually
78+
`Ctrl-C` from a terminal. When gracefully exiting, the agent first notifies
79+
the cluster it intends to leave the cluster. This way, other cluster members
80+
notify the cluster that the node has _left_.
81+
82+
Alternatively, you can force kill the agent by sending it a kill signal.
83+
When force killed, the agent ends immediately. The rest of the cluster will
84+
eventually (usually within seconds) detect that the node has died and will
85+
notify the cluster that the node has _failed_.
86+
87+
It is especially important that a server node be allowed to gracefully leave,
88+
so that there will be a minimal impact on availability as the server leaves
89+
the consensus quorum.
90+
91+
For client agents, the difference between a node _failing_ and a node _leaving_
92+
may not be important for your use case. For example, for a web server and load
93+
balancer setup, both result in the same action: remove the web node
94+
from the load balancer pool. But for other situations, you may handle
95+
each scenario differently.

‎doc/content/pages/docs/agent/checks.md

+79
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,79 @@
1+
Title: Check Definition
2+
Slug: docs/agent/checks
3+
4+
5+
# Checks
6+
7+
One of the primary roles of the agent is the management of system and
8+
application level health checks. A health check is considered to be application
9+
level if it associated with a service. A check is defined in a configuration file,
10+
or added at runtime over the HTTP interface.
11+
12+
There are two different kinds of checks:
13+
14+
* Script + Interval - These checks depend on invoking an external application
15+
which does the health check and exits with an appropriate exit code, potentially
16+
generating some output. A script is paired with an invocation interval (e.g.
17+
every 30 seconds). This is similar to the Nagios plugin system.
18+
19+
* TTL - These checks retain their last known state for a given TTL. The state
20+
of the check must be updated periodically over the HTTP interface. If an
21+
external system fails to update the status within a given TTL, the check is
22+
set to the failed state. This mechanism is used to allow an application to
23+
directly report its health. For example, a web app can periodically curl the
24+
endpoint, and if the app fails, then the TTL will expire and the health check
25+
enters a critical state. This is conceptually similar to a dead man's switch.
26+
27+
## Check Definition
28+
29+
A check definition that is a script looks like:
30+
31+
{
32+
"check": {
33+
"id": "mem-util",
34+
"name": "Memory utilization",
35+
"script": "/usr/local/bin/check_mem.py",
36+
"interval": "10s"
37+
}
38+
}
39+
40+
A TTL based check is very similar:
41+
42+
{
43+
"check": {
44+
"id": "web-app",
45+
"name": "Web App Status",
46+
"notes": "Web app does a curl internally every 10 seconds",
47+
"ttl": "30s"
48+
}
49+
}
50+
51+
Both types of definitions must include a `name`, and may optionally
52+
provide an `id` and `notes` field. The `id` is set to the `name` if not
53+
provided. It is required that all checks have a unique ID per node, so if names
54+
might conflict then unique ID's should be provided.
55+
56+
The `notes` field is opaque to XXX, but may be used for human
57+
readable descriptions. The field is set to any output that a script
58+
generates, and similarly the TTL update hooks can update the `notes`
59+
as well.
60+
61+
To configure a check, either provide it as a `-config-file` option to the
62+
agent, or place it inside the `-config-dir` of the agent. The file must
63+
end in the ".json" extension to be loaded by XXX. Check definitions can
64+
also be updated by sending a `SIGHUP` to the agent. Alternatively, the
65+
check can be registered dynamically using the [HTTP API](/docs/agent/http.html).
66+
67+
## Check Scripts
68+
69+
A check script is generally free to do anything to determine the status
70+
of the check. The only limitations placed are the exit codes must convey
71+
a specific meaning. Specifically:
72+
73+
* Exit code 0 - Check is passing
74+
* Exit code 1 - Check is warning
75+
* Any other code - Check is failing
76+
77+
This is the only convention that XXX depends on. Any output of the script
78+
will be captured and stored in the `notes` field so that it can be viewed
79+
by human operators.

0 commit comments

Comments
 (0)