зеркало из https://github.com/microsoft/CCF.git
Remove references to test network script in documentation (#1892)
This commit is contained in:
Amaury Chamayou
GitHub
Родитель
31ad32fc86
Коммит
ecbac6deff
|
|
@ -51,7 +51,7 @@ Each member and user is identified by the cert with which they were registered w
|
|||
|
||||
When using curl the server's identity is provided by ``--cacert`` and the client identity by ``--cert`` and ``--key``. Resources under the ``/gov`` path require member identities, while those under ``/app`` typically require user identities.
|
||||
|
||||
These certificates and keys are copied by the start network script to the common workspace directory, displayed by the start network script. By default this is ``workspace/test_network_common``.
|
||||
These certificates and keys are copied by the sandbox script to the common workspace directory, displayed by the start network script. By default this is ``workspace/sandbox_common``.
|
||||
|
||||
Basic Commands
|
||||
--------------
|
||||
|
|
@ -60,7 +60,7 @@ For ease of access, we copy the generated PEMs to the current directory:
|
|||
|
||||
.. code-block:: bash
|
||||
|
||||
$ cp workspace/test_network_common/*.pem .
|
||||
$ cp workspace/sandbox_common/*.pem .
|
||||
|
||||
Now we can submit a first command, to find the current commit index of the test network:
|
||||
|
||||
|
|
@ -118,10 +118,10 @@ Note that the paths to these handlers is arbitrary. The names of the endpoints d
|
|||
|
||||
.. code-block:: bash
|
||||
|
||||
$ grep "Logged to public table" workspace/test_network_0/0.ledger/ledger_1 -q && echo "Visible" || echo "Not visible"
|
||||
$ grep "Logged to public table" workspace/sandbox_0/0.ledger/ledger_1 -q && echo "Visible" || echo "Not visible"
|
||||
Visible
|
||||
|
||||
$ grep "Logged to private table" workspace/test_network_0/0.ledger/ledger_1 -q && echo "Visible" || echo "Not visible"
|
||||
$ grep "Logged to private table" workspace/sandbox_0/0.ledger/ledger_1 -q && echo "Visible" || echo "Not visible"
|
||||
Not visible
|
||||
|
||||
.. _curl: https://curl.haxx.se/
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ Applications can be written in JavaScript or C++. An application consists of a c
|
|||
|
||||
.. warning:: Lua applications will soon be deprecated.
|
||||
|
||||
These endpoints can read or mutate the state of a unique :doc:`developers/kv/index` that represents the internal state of the application. Applications define a set of ``Maps`` (see :ref:`developers/kv/kv_how_to:Creating a Map`), mapping from a key to a value. When an application endpoint is triggered, the effects on the Store are committed atomically.
|
||||
These endpoints can read or mutate the state of a unique :ref:`developers/kv/index:Key-Value Store` that represents the internal state of the application. Applications define a set of ``Maps`` (see :ref:`developers/kv/kv_how_to:Creating a Map`), mapping from a key to a value. When an application endpoint is triggered, the effects on the Store are committed atomically.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
|
|
|||
|
|
@ -2,7 +2,73 @@
|
|||
Running CCF Applications
|
||||
========================
|
||||
|
||||
.. note:: For a quick and easy way to run a CCF application locally, try :doc:`/quickstart/test_network`, specifying the desired enclave image.
|
||||
.. note:: Before starting a CCF sandbox environment, make sure that:
|
||||
|
||||
- The CCF runtime environment has successfully been setup (see :ref:`environment setup instructions <quickstart/run_setup:Setup CCF Runtime Environment>`).
|
||||
- CCF is installed (see :ref:`installation steps <quickstart/install:Install>`)
|
||||
|
||||
The quickest way to start a CCF sandbox is to use the `sandbox.sh <https://github.com/microsoft/CCF/blob/master/tests/sandbox/sandbox.sh>`_ test script, specifying the :doc:`enclave image </developers/index>` to run.
|
||||
|
||||
The script creates a new one node CCF test network running locally. All the governance requests required to open the network to users are automatically issued.
|
||||
|
||||
For example, deploying the ``liblogging`` example application:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ /opt/ccf/bin/sandbox.sh --package ./liblogging.virtual.so
|
||||
Setting up Python environment...
|
||||
Python environment successfully setup
|
||||
[16:14:05.294] Starting 1 CCF nodes...
|
||||
[16:14:05.295] Virtual mode enabled
|
||||
[16:14:10.010] Started CCF network with the following nodes:
|
||||
[16:14:10.011] Node [0] = https://127.0.0.1:8000
|
||||
[16:14:10.011] You can now issue business transactions to the ./liblogging.virtual.so application.
|
||||
[16:14:10.011] Keys and certificates have been copied to the common folder: /data/src/CCF/build/workspace/sandbox_common
|
||||
[16:14:10.011] See https://microsoft.github.io/CCF/master/users/issue_commands.html for more information.
|
||||
[16:14:10.011] Press Ctrl+C to shutdown the network.
|
||||
|
||||
.. note::
|
||||
|
||||
- ``sandbox.sh`` defaults to using CCF's `virtual` mode, which does not require or make use of SGX. To load debug or release enclaves and make use of SGX, ``--enclave-type`` must be set to the right value, for example: ``sandbox.sh --enclave-type release -p ./liblogging.enclave.so.signed``
|
||||
- The ``--verbose`` argument can be used to display all commands issued by operators and members to start the network.
|
||||
- Snapshots can be generated at regular intervals by the primary node of the service using the ``--snapshot-tx-interval <interval>`` option.
|
||||
|
||||
The log files (``out`` and ``err``) and ledger directory (``<node_id>.ledger``) for each CCF node can be found under ``./workspace/sandbox_<node_id>``.
|
||||
|
||||
.. note:: The first time the command is run, a Python virtual environment will be created. This may take a few seconds. It will not be run the next time the ``sandbox.sh`` script is started.
|
||||
|
||||
In a different terminal, using the local IP address and port of the CCF nodes displayed by the command (e.g. ``https://127.0.0.1:8000`` for node ``0``), it is then possible for users to :ref:`issue business requests <users/issue_commands:Issuing Commands>`.
|
||||
|
||||
Recovering a Service
|
||||
--------------------
|
||||
|
||||
The ``sandbox.sh`` script can also be used to automatically recover a defunct network, as per the steps described :ref:`here <members/accept_recovery:Accepting Recovery and Submitting Shares>`. The ledger to be recovered (``--ledger-dir``) and the directory containing the members and users identities (``--common-dir``) should be passed as arguments to the script.
|
||||
|
||||
Additionally, if snapshots were generated by the defunct service (using the ``--snapshot-tx-interval <interval>`` option), the recovery procedure can be significantly sped up by re-starting from the latest available snapshot (``--snapshot-dir``).
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ cp -r ./workspace/sandbox_0/0.ledger .
|
||||
$ cp -r ./workspace/sandbox_0/snapshots . # Optional, only if snapshots are available
|
||||
$ /opt/ccf/bin/sandbox.sh -p ./liblogging.virtual.so --recover --ledger-dir 0.ledger --common-dir ./workspace/sandbox_common/ [--snapshot-dir snapshots]
|
||||
Setting up Python environment...
|
||||
Python environment successfully setup
|
||||
[16:24:29.563] Starting 1 CCF nodes...
|
||||
[16:24:29.563] Recovering network from:
|
||||
[16:24:29.563] - Common directory: ./workspace/sandbox_common/
|
||||
[16:24:29.563] - Ledger: 0.ledger
|
||||
[16:24:29.563] No available snapshot to recover from. Entire transaction history will be replayed.
|
||||
[16:24:32.885] Started CCF network with the following nodes:
|
||||
[16:24:32.885] Node [1] = https://127.0.0.1:8000
|
||||
[16:24:32.885] You can now issue business transactions to the liblogging.enclave.so.signed application.
|
||||
[16:24:32.885] Keys and certificates have been copied to the common folder: ./workspace/sandbox_common/
|
||||
[16:24:32.885] See https://microsoft.github.io/CCF/master/users/issue_commands.html for more information.
|
||||
[16:24:32.885] Press Ctrl+C to shutdown the network.
|
||||
|
||||
The effects of transactions committed by the defunct network should then be recovered. Users can also :ref:`issue new business requests <users/issue_commands:Issuing Commands>`.
|
||||
|
||||
.. note:: The ``--ledger-recovery-timeout`` argument should be used to specify the maximum timeout (in seconds) that the script will wait for CCF to recover the ledger. Depending on the size of the ledger to recover, this timeout may have to be set to a large value.
|
||||
|
||||
|
||||
Debugging
|
||||
---------
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ Start Here
|
|||
|
||||
- :doc:`/concepts`
|
||||
- :doc:`/quickstart/install`
|
||||
- :doc:`Run a sample CCF application </quickstart/test_network>`
|
||||
- :doc:`Run a sample CCF application </developers/run_app>`
|
||||
- :doc:`Use CCF </users/index>`
|
||||
- :doc:`/quickstart/create_vm`
|
||||
- `What's new in the latest version of CCF? <https://github.com/microsoft/CCF/releases/latest>`_
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ Accepting Recovery and Submitting Shares
|
|||
|
||||
.. note:: Before members can initiate the end of the recovery procedure, operators should have started a new network and recovered all public transactions. See :ref:`details for public recovery operator procedure <operators/recovery:Establishing a Recovered Public Network>`.
|
||||
|
||||
.. note:: See :ref:`quickstart/test_network:Recovering a Service` for an automated way to recover a defunct CCF service.
|
||||
.. note:: See :ref:`developers/run_app:Recovering a Service` for an automated way to recover a defunct CCF service.
|
||||
|
||||
Accepting Recovery
|
||||
------------------
|
||||
|
|
|
|||
|
|
@ -6,7 +6,6 @@
|
|||
:hidden:
|
||||
|
||||
install
|
||||
test_network
|
||||
build
|
||||
create_vm
|
||||
build_setup
|
||||
|
|
|
|||
|
|
@ -1,69 +0,0 @@
|
|||
Using CCF Sandbox Environment
|
||||
=============================
|
||||
|
||||
.. note:: Before starting a CCF sandbox environment, make sure that:
|
||||
|
||||
- The CCF runtime environment has successfully been setup (see :ref:`environment setup instructions <quickstart/run_setup:Setup CCF Runtime Environment>`).
|
||||
- CCF is installed (see :ref:`installation steps <quickstart/install:Install>`)
|
||||
|
||||
The quickest way to start a CCF sandbox is to use the `sandbox.sh <https://github.com/microsoft/CCF/blob/master/tests/sandbox/sandbox.sh>`_ test script, specifying the :doc:`enclave image </developers/index>` to run.
|
||||
|
||||
The script creates a new one node CCF test network running locally. All the governance requests required to open the network to users are automatically issued.
|
||||
|
||||
For example, deploying the ``liblogging`` example application:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ /opt/ccf/bin/sandbox.sh --package ./liblogging.virtual.so
|
||||
Setting up Python environment...
|
||||
Python environment successfully setup
|
||||
[16:14:05.294] Starting 1 CCF nodes...
|
||||
[16:14:05.295] Virtual mode enabled
|
||||
[16:14:10.010] Started CCF network with the following nodes:
|
||||
[16:14:10.011] Node [0] = https://127.0.0.1:8000
|
||||
[16:14:10.011] You can now issue business transactions to the ./liblogging.virtual.so application.
|
||||
[16:14:10.011] Keys and certificates have been copied to the common folder: /data/src/CCF/build/workspace/sandbox_common
|
||||
[16:14:10.011] See https://microsoft.github.io/CCF/master/users/issue_commands.html for more information.
|
||||
[16:14:10.011] Press Ctrl+C to shutdown the network.
|
||||
|
||||
.. note::
|
||||
|
||||
- ``sandbox.sh`` defaults to using CCF's `virtual` mode, which does not require or make use of SGX. To load debug or release enclaves and make use of SGX, ``--enclave-type`` must be set to the right value, for example: ``sandbox.sh --enclave-type release -p ./liblogging.enclave.so.signed``
|
||||
- The ``--verbose`` argument can be used to display all commands issued by operators and members to start the network.
|
||||
- Snapshots can be generated at regular intervals by the primary node of the service using the ``--snapshot-tx-interval <interval>`` option.
|
||||
|
||||
The log files (``out`` and ``err``) and ledger directory (``<node_id>.ledger``) for each CCF node can be found under ``./workspace/sandbox_<node_id>``.
|
||||
|
||||
.. note:: The first time the command is run, a Python virtual environment will be created. This may take a few seconds. It will not be run the next time the ``sandbox.sh`` script is started.
|
||||
|
||||
In a different terminal, using the local IP address and port of the CCF nodes displayed by the command (e.g. ``https://127.0.0.1:8000`` for node ``0``), it is then possible for users to :ref:`issue business requests <users/issue_commands:Issuing Commands>`.
|
||||
|
||||
Recovering a Service
|
||||
--------------------
|
||||
|
||||
The ``sandbox.sh`` script can also be used to automatically recover a defunct network, as per the steps described :ref:`here <members/accept_recovery:Accepting Recovery and Submitting Shares>`. The ledger to be recovered (``--ledger-dir``) and the directory containing the members and users identities (``--common-dir``) should be passed as arguments to the script.
|
||||
|
||||
Additionally, if snapshots were generated by the defunct service (using the ``--snapshot-tx-interval <interval>`` option), the recovery procedure can be significantly sped up by re-starting from the latest available snapshot (``--snapshot-dir``).
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ cp -r ./workspace/sandbox_0/0.ledger .
|
||||
$ cp -r ./workspace/sandbox_0/snapshots . # Optional, only if snapshots are available
|
||||
$ /opt/ccf/bin/sandbox.sh -p ./liblogging.virtual.so --recover --ledger-dir 0.ledger --common-dir ./workspace/sandbox_common/ [--snapshot-dir snapshots]
|
||||
Setting up Python environment...
|
||||
Python environment successfully setup
|
||||
[16:24:29.563] Starting 1 CCF nodes...
|
||||
[16:24:29.563] Recovering network from:
|
||||
[16:24:29.563] - Common directory: ./workspace/sandbox_common/
|
||||
[16:24:29.563] - Ledger: 0.ledger
|
||||
[16:24:29.563] No available snapshot to recover from. Entire transaction history will be replayed.
|
||||
[16:24:32.885] Started CCF network with the following nodes:
|
||||
[16:24:32.885] Node [1] = https://127.0.0.1:8000
|
||||
[16:24:32.885] You can now issue business transactions to the liblogging.enclave.so.signed application.
|
||||
[16:24:32.885] Keys and certificates have been copied to the common folder: ./workspace/sandbox_common/
|
||||
[16:24:32.885] See https://microsoft.github.io/CCF/master/users/issue_commands.html for more information.
|
||||
[16:24:32.885] Press Ctrl+C to shutdown the network.
|
||||
|
||||
The effects of transactions committed by the defunct network should then be recovered. Users can also :ref:`issue new business requests <users/issue_commands:Issuing Commands>`.
|
||||
|
||||
.. note:: The ``--ledger-recovery-timeout`` argument should be used to specify the maximum timeout (in seconds) that the script will wait for CCF to recover the ledger. Depending on the size of the ledger to recover, this timeout may have to be set to a large value.
|
||||
|
|
@ -1,7 +1,7 @@
|
|||
Python Client Tutorial
|
||||
======================
|
||||
|
||||
This tutorial describes how a Python client can securely issue requests to a running CCF network. It is assumed that the CCF network has already been started (e.g. after having :doc:`deployed a sandbox service </quickstart/test_network>`).
|
||||
This tutorial describes how a Python client can securely issue requests to a running CCF network. It is assumed that the CCF network has already been started (e.g. after having :doc:`deployed a sandbox service </developers/run_app>`).
|
||||
|
||||
.. note:: See :ref:`Python Client API <users/python_api:Python Client API>` for the complete API specification.
|
||||
|
||||
|
|
@ -26,7 +26,7 @@ Set the following CCF node variables:
|
|||
port = <node-port> # Node port (int)
|
||||
ca = "<path/to/network/cert>" # Network certificate path
|
||||
|
||||
.. note:: :doc:`When starting a CCF sandbox </quickstart/test_network>`, use any node's IP address and port number. All certificates and keys can be found in the associated ``common_dir`` folder.
|
||||
.. note:: :doc:`When starting a CCF sandbox </developers/run_app>`, use any node's IP address and port number. All certificates and keys can be found in the associated ``common_dir`` folder.
|
||||
|
||||
Create a new :py:class:`ccf.clients.CCFClient` instance which will create a secure TLS connection to the target node part of the network specified via ``ca``:
|
||||
|
||||
|
|
|
|||
13
livehtml.sh
13
livehtml.sh
|
|
@ -2,4 +2,17 @@
|
|||
# Copyright (c) Microsoft Corporation. All rights reserved.
|
||||
# Licensed under the Apache 2.0 License.
|
||||
|
||||
set -e
|
||||
|
||||
echo "Setting up Python environment..."
|
||||
if [ ! -f "env/bin/activate" ]
|
||||
then
|
||||
python3.8 -m venv env
|
||||
fi
|
||||
|
||||
source env/bin/activate
|
||||
pip install --disable-pip-version-check -q -U -e ./python/
|
||||
pip install --disable-pip-version-check -q -U -r ./doc/requirements.txt
|
||||
echo "Python environment successfully setup"
|
||||
|
||||
sphinx-autobuild -b html doc doc/html --host localhost --port 8080
|
||||
|
|
@ -11,8 +11,8 @@ if [ ! -f "env/bin/activate" ]
|
|||
fi
|
||||
|
||||
source env/bin/activate
|
||||
pip install -q -U -e ../python/
|
||||
pip install -q -U -r ../tests/requirements.txt
|
||||
pip install --disable-pip-version-check -q -U -e ../python/
|
||||
pip install --disable-pip-version-check -q -U -r ../tests/requirements.txt
|
||||
echo "Python environment successfully setup"
|
||||
|
||||
# Export where the VENV has been set, so tests running
|
||||
|
|
|
|||
Загрузка…
Ссылка в новой задаче