Dark-Alex-17/kapow
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

doc: typos and style fixes

Browse Source
This commit is contained in:
pancho horrillo
2019-12-10 16:09:35 +01:00
parent 84e481f78f
commit b4bc08f491
4 changed files with 90 additions and 50 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/source/the_project/quickstart.rst
+33 -20
View File
@@ -19,15 +19,18 @@ this:
Our organization has an external host that acts as a bridge between our intranet
an the public Internet.
**Our goal: Our team needs to check if the** :samp:`Internal Host` **is alive.**
**Our goal: Our team must be able to check if the :samp:`Internal Host` is alive on an ongoing basis.**
Limitations and Constraints
---------------------------
1. We **don't want** to **grant access** to the :samp:`*External Host*` to anybody.
2. We **don't want** to manage VPNs or any similar solutions to access :samp:`Internal Host` from the Internet.
3. We **want to limit the actions** that a user can perform in our intranet while it is checking if :samp:`Internal Host` is alive.
1. We **don't want** to **grant access** to the :samp:`External Host` to
anybody.
2. We **don't want** to manage VPNs or any similar solutions to access
:samp:`Internal Host` from the Internet.
3. We **want to limit the actions** that a user can perform in our intranet
while it is checking if :samp:`Internal Host` is alive.
4. We **want** to use the most standard mechanism. Easy to use and automate.
5. We **don't have a budget** to invest in a custom solution.
@@ -35,7 +38,7 @@ Limitations and Constraints
The Desired Solution
--------------------
After analyzing the problem and our with our goal in mind, we conclude that it
After analyzing the problem and with our goal in mind, we conclude that it
is enough **to use a simple** :samp:`ping` **to** :samp:`Internal Host`.
So, the next step is to **analyze how to perform the ping.**
@@ -44,9 +47,9 @@ So, the next step is to **analyze how to perform the ping.**
Accessing via SSH to :samp:`External Host`
++++++++++++++++++++++++++++++++++++++++++
If we choose this option then we need to create a user in the host and grant
them access via :samp:`SSH` to :samp:`External Host` for every person that needs
to check the :samp:status of `Internal host`.
If we choose this option, then, for every person that needs to check the status
of :samp:`Internal host`, we need to create a user in the ``Extarnal Host`` and
grant them ``SSH`` access.
Conclusion: **Not a good idea.**
@@ -80,10 +83,14 @@ Using *Kapow!* (spoiler: it's the winner!)
Ok, let's analyze *Kapow!* and check if it is compatible with our constraints:
1. *Kapow!* is Open Source, so **it's also free as in beer**.
2. By using kapow! we don't need to code our own solution, so we **don't have to waste time**.
3. By using *Kapow!* we can run any command in the :samp:`External Host` limiting the command parameters, so **it's safe**.
4. By using *Kapow!* we can launch any system command as an HTTP API easily, so **we don't need to grant login access to anybody to** :samp:`External Host`.
1. *Kapow!* is Open Source, so it's also **free as in beer**.
2. By using *Kapow!* we don't need to code our own solution, so we **don't have
to waste time**.
3. By using *Kapow!* we can run any command in the :samp:`External Host`
limiting the command parameters, so **it's safe**.
4. By using *Kapow!* we can launch any system command as an ``HTTP API`` easily, so
**we don't need to grant login access to** :samp:`External Host` **to
anybody**.
Conclusion: *Kapow!* **is the best choice.**
@@ -93,19 +100,20 @@ Reasons: It satisfies all of our requirements.
Using Kapow!
------------
In order to get our example :ref:`Scenario <quickstart_image>` working we need to follow the below steps.
In order to get our example :ref:`Scenario <quickstart_image>` working we need
to follow the steps below.
Install Kapow!
++++++++++++++
Follow :doc:`Install *Kapow!* <install_and_configure>` instructions.
Follow the :doc:`Installing Kapow! <install_and_configure>` instructions.
Write a ``ping.pow`` File
+++++++++++++++++++++++++
*Kapow!* uses plain text files (called ``POW`` files) so you can define the
*Kapow!* uses plain text files (called ``pow`` files) so you can define the
endpoints you want to expose the system command with. For our example we need a
file like this:
@@ -116,16 +124,21 @@ file like this:
Explanation:
1. :samp:`kapow route add /ping` - adds a new HTTP API endpoint at :samp:`/ping` path in the *Kapow!* server. You have to use `GET` method to invoke the endpoint.
2. :samp:`-c` - after this parameter we write the system command that *Kapow!* will run each time the endpoint is invoked.
3. :samp:`ping -c 1 10.10.10.100` - sends 1 ping package to the host *10.10.10.100*, i.e. :samp:`Internal Host`.
4. :samp:`| kapow set /response/body` - writes the output of `ping` to the body of the response, so you can see it.
1. :samp:`kapow route add /ping` - adds a new ``HTTP API`` endpoint at :samp:`/ping`
path in the *Kapow!* server. You have to use ``GET`` method to invoke the
endpoint.
2. :samp:`-c` - after this parameter we write the system command that *Kapow!*
will run each time the endpoint is invoked.
3. :samp:`ping -c 1 10.10.10.100` - sends 1 ping package to the host
*10.10.10.100*, i.e. :samp:`Internal Host`.
4. :samp:`| kapow set /response/body` - writes the output of `ping` to the body
of the response, so you can see it.
Launch the Service
++++++++++++++++++
At this point we only need to launch `kapow` with our :samp:`ping.pow`:
At this point we only need to launch ``kapow`` with our :samp:`ping.pow`:
.. code-block:: console