-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathindex.xml
76 lines (61 loc) · 5.56 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
<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
<title>marabunta</title>
<link>https://marabunta.io/</link>
<description>Recent content on marabunta</description>
<generator>Hugo -- gohugo.io</generator>
<language>en-us</language>
<lastBuildDate>Thu, 08 Nov 2018 10:33:05 +0100</lastBuildDate>
<atom:link href="https://marabunta.io/index.xml" rel="self" type="application/rss+xml" />
<item>
<title>How It Works</title>
<link>https://marabunta.io/post/how-it-works/</link>
<pubDate>Thu, 08 Nov 2018 10:33:05 +0100</pubDate>
<guid>https://marabunta.io/post/how-it-works/</guid>
<description>In a nutshell. The task life cycle could be summarized in the following steps:
A task is submitted via an HTTP API The task will be stored in a database (MySQL) for keeping track of it Based on the schedule, when is time to run it will be moved to a Redis queue The task is dispatched via gRPC to the targets The status of the task will be updated in the database The process is pretty straightforward one of the main design goals is to avoid unnecessary complexity, giving priority to performance and simple orchestration of the tasks at all cost as for the maintenance and scalability of the full system.</description>
</item>
<item>
<title>Why</title>
<link>https://marabunta.io/post/why/</link>
<pubDate>Tue, 06 Nov 2018 15:13:13 +0100</pubDate>
<guid>https://marabunta.io/post/why/</guid>
<description>There are many good tools, frameworks offering multiple solutions for managing jobs, tasks, queues, etc, many of them are listed here http://queues.io/.
Technology changes and with this, new tools emerge. Days back you could be using gearman, these days probably nats.io or even ansible ad-hoc:
$ ansible all -a &quot;ping -c3 1.1.1.1&quot; -u devops --become Just as an example that with multiple technologies the same result can be achieved, some relatively easy, others faster, etc.</description>
</item>
<item>
<title>prototype</title>
<link>https://marabunta.io/post/prototype/</link>
<pubDate>Mon, 05 Nov 2018 11:02:09 +0100</pubDate>
<guid>https://marabunta.io/post/prototype/</guid>
<description>The big picture Tasks are stored in a MySQL, a worker (scheduler) periodically check the schedules and creates, updates or remove tasks from a live queue that uses redis, rabbitmq, nats, etc as a backend. One or more clients consume the queue and via a bidirectional gRPC stream dispatch the task to the proper client, if the task is finished, the client updates the result/status via gRPC Unary if not task is re-queued.</description>
</item>
<item>
<title>Payload</title>
<link>https://marabunta.io/post/payload/</link>
<pubDate>Fri, 10 Nov 2017 00:31:54 +0100</pubDate>
<guid>https://marabunta.io/post/payload/</guid>
<description>The Schema { &quot;description&quot;: &quot;optional&quot;, &quot;enabled&quot;: 1, &quot;name&quot;: &quot;name of the tasks&quot;, &quot;payload&quot;: { &quot;attachments&quot;: { &quot;/tmp/ok.jpg&quot;: &quot;base64&quot; }, &quot;metadata&quot;: { &quot;key&quot;: &quot;value&quot; }, &quot;task&quot;: &quot;command args&quot; }, &quot;retries&quot;: 0, &quot;target&quot;: &quot;where to execute the task&quot;, &quot;when&quot;: &quot;when to execute it&quot; } Field Mandatory description description NO Description of the task enabled NO Defaults to 1 (yes) name YES Name of the task payload YES payload for the task (check the payload schema) retries NO The number of tries if the task fails, defaults to 0 target YES The name of the target where the task will be run when YES schedule for the task Payload schema &quot;payload&quot;: { &quot;attachments&quot;: { &quot;/tmp/ok.</description>
</item>
<item>
<title>API</title>
<link>https://marabunta.io/post/api/</link>
<pubDate>Fri, 10 Nov 2017 00:00:54 +0100</pubDate>
<guid>https://marabunta.io/post/api/</guid>
<description> All tasks are managed via an HTTP REST API.
Creating a task: Enpoint: /tasks/
HTTP method CRUD Description Status code POST Create Create a task 201 (OK) GET Read Get all tasks 200 (OK) GET Read /tasks/:UUID Get a task 200 (OK), 404 (If ID not found) PUT Update /tasks/:UUID Update/modify a task 204 (OK), 404 (If ID not found) DELETE Delete /tasks/:UUID Delete a task 204 (OK), 404 (If ID not found) </description>
</item>
<item>
<title>About</title>
<link>https://marabunta.io/about/</link>
<pubDate>Fri, 30 Jun 2017 14:44:15 +0200</pubDate>
<guid>https://marabunta.io/about/</guid>
<description>What is marabunta? From its definition, marabunta is one of the names given to army ants.
The idea of the project is to create something similar applying, following nature knowledge and patterns using a client-server topology aiming to create a distributed task manager using gRPC at is core with an HTTP REST management interface.
Think about it as if your whole infrastructure nodes where a bunch of ants at your command in where you could do distributed tasks using all your nodes at once, in a defined group or in a single node, keeping track of each task result and output.</description>
</item>
</channel>
</rss>