diff --git a/docs/architecture.rst b/docs/architecture.rst
index a371e68e3e..f687d1f9ec 100644
--- a/docs/architecture.rst
+++ b/docs/architecture.rst
@@ -8,40 +8,52 @@ Architecture
Kopia Repository Server Workflow
-=======================
+================================
-Introducting Kopia
+Introducing Kopia
------------------
-Kopia is a powerful, cross-platform tool for managing encrypted backups in the cloud.
-It provides fast and secure backups, using compression, data deduplication, and client-side end-to-end encryption.
-It supports a variety of backup storage targets, including object stores, which allows users to choose the storage provider that better addresses their needs.
-In Kopia, these storage locations are called repositories. It is a lock-free system that allows concurrent multi-client operations including garbage collection.
-To explore other features of Kopia, see its `documentation`_
+Kopia is a powerful, cross-platform tool for managing encrypted backups
+in the cloud. It provides fast and secure backups, using compression,
+data `de-duplication`, and client-side end-to-end encryption. It supports
+a variety of backup storage targets, including object stores, which allows
+users to choose the storage provider that better addresses their needs.
+In Kopia, these storage locations are called repositories. It is a
+lock-free system that allows concurrent multi-client operations
+including garbage collection. To explore other features of Kopia,
+see its `documentation `_
Kopia Repository Server
-----------------------
-A Kopia Repository Server allows Kopia clients proxy access to the backend storage location through it.
-Kopia Repository. At any time, a repository server can only connect to a single repository. Due to this a separate instance of the server will be used for each repository.
+A Kopia Repository Server allows Kopia clients proxy access to the backend storage
+location through it. At any time, a repository server can only connect to a single
+repository. Due to this a separate instance of the server will be used for each
+repository.
-In Kanister, the server will comprise a Kubernetes Pod, Service. The pod runs the kopia repository
-server process that will be used by kopia clients to perform backup and restore. Kopia clients would
-only need a username/password and service name to connect to server without the need to know
-the backend storage location. This provides enhanced security since only authorized users will be allowed
-to access the kopia repository server. These authorized users need to be added to the server
-before starting the server
+In Kanister, the server will comprise a Kubernetes Pod, Service. The pod runs the
+kopia repository server process that will be used by kopia clients to perform
+backup and restore. Kopia clients would only need a username/password and
+service name to connect to server without the need to know the backend storage
+location. This provides enhanced security since only authorized users will be
+allowed to access the kopia repository server. These authorized users need to be
+added to the server before starting the server.
Kopia Repository
----------------
-The backup storage location is called a "Repository" in Kopia.
-Only a single repository can exist at a particular path in the backend storage location. Users opting to use separate repositories are recommended to use unique path prefixes for each repository.
-For example, a repository for a namespace called monitoring on S3 storage bucket called test-bucket could be created at the location ``s3://test-bucket//repo/``
-Accessing the repository requires the storage location and credential information similar to a Kanister Profile CR and a unique password used by Kopia during encryption, along with a unique
-path prefix mentioned above.
+The backup storage location is called a "Repository" in Kopia. Only a single
+repository can exist at a particular path in the backend storage location.
+Users opting to use separate repositories are recommended to use unique path
+prefixes for each repository. For example, a repository for a namespace called
+monitoring on S3 storage bucket called test-bucket could be created at the
+location ``s3://test-bucket//repo/``. Accessing
+the repository requires the storage location and credential information similar
+to a Kanister Profile CR and a unique password used by Kopia during encryption,
+along with a unique path prefix mentioned above.
-To know more about the design of kopia repository server controller refer its `design documentation
+To know more about the design of kopia repository server controller refer
+its `design documentation ` _
The design of Kanister follows the operator pattern. This means
Kanister defines its own resources and interacts with those resources
@@ -402,6 +414,8 @@ As a reference, below is an example of a Profile and the corresponding secret.
example_key_id:
example_secret_access_key:
+.. _repository_servers:
+
RepositoryServers
-----------------
@@ -411,7 +425,7 @@ kopia repository server.
.. note::
Secrets referenced in the CR should be created in the format referenced
- in the :ref:`Repository Server Secrets` section
+ in the :ref:`Repository Server Secrets` section
The definition of ``Repository Server`` is:
@@ -421,10 +435,10 @@ The definition of ``Repository Server`` is:
// RepositoryServer manages the lifecycle of Kopia Repository Server within a Pod
type RepositoryServer struct {
- metav1.TypeMeta `json:",inline"`
- metav1.ObjectMeta `json:"metadata,omitempty"`
- Spec RepositoryServerSpec `json:"spec"`
- Status RepositoryServerStatus `json:"status"`
+ metav1.TypeMeta `json:",inline"`
+ metav1.ObjectMeta `json:"metadata,omitempty"`
+ Spec RepositoryServerSpec `json:"spec"`
+ Status RepositoryServerStatus `json:"status"`
}
Repository Server ``Spec`` field is defined as follows:
@@ -433,9 +447,9 @@ The definition of ``Repository Server`` is:
:linenos:
type RepositoryServerSpec struct {
- Storage Storage `json:"storage"`
- Repository Repository `json:"repository"`
- Server Server `json:"server"`
+ Storage Storage `json:"storage"`
+ Repository Repository `json:"repository"`
+ Server Server `json:"server"`
}
- ``Storage`` field in the ``RepositoryServerSpec`` contains the location
@@ -445,34 +459,33 @@ The definition of ``Repository Server`` is:
:linenos:
type Storage struct {
- SecretRef corev1.SecretReference `json:"secretRef"`
- CredentialSecretRef corev1.SecretReference `json:"credentialSecretRef"`
+ SecretRef corev1.SecretReference `json:"secretRef"`
+ CredentialSecretRef corev1.SecretReference `json:"credentialSecretRef"`
}
^ ``SecretRef`` and ``CredentialSecretRef`` are the references to location
secrets
-
-- ``Repository`` field in CR ``spec`` has details to connect to kopia repository created
+
+- ``Repository`` field in CR ``spec`` has details to connect to kopia repository created
in the above location storage
.. code-block:: go
:linenos:
type Repository struct {
- RootPath string `json:"rootPath"`
- Username string `json:"username"`
- Hostname string `json:"hostname"`
- PasswordSecretRef corev1.SecretReference `json:"passwordSecretRef"`
+ RootPath string `json:"rootPath"`
+ Username string `json:"username"`
+ Hostname string `json:"hostname"`
+ PasswordSecretRef corev1.SecretReference `json:"passwordSecretRef"`
CacheSizeSettings CacheSizeSettings `json:"cacheSizeSettings,omitempty"`
}
-
-^ ``RootPath`` is the path for the kopia repository. It is the subpath within
+^ ``RootPath`` is the path for the kopia repository. It is the sub-path within
the path prefix specified in storage location
^ ``Username`` is an optional field used to override the default username while
connecting to kopia repository
-^ ``Hostname`` is an optional field used to override the default hostname while
+^ ``Hostname`` is an optional field used to override the default host name while
connecting to kopia repository
Kopia identifies users by ``username@hostname`` and uses the values
@@ -490,10 +503,10 @@ To know more about the kopia caches, refer to the `kopia caching documentation <
.. code-block:: go
:linenos:
-
+
type CacheSizeSettings struct {
- Metadata string `json:"metadata"`
- Content string `json:"content"`
+ Metadata string `json:"metadata"`
+ Content string `json:"content"`
}
- ``Server`` field in the CR spec has references to all the secrets
@@ -503,58 +516,64 @@ To know more about the kopia caches, refer to the `kopia caching documentation <
:linenos:
type Server struct {
- UserAccess UserAccess `json:"userAccess"`
- AdminSecretRef corev1.SecretReference `json:"adminSecretRef"`
- TLSSecretRef corev1.SecretReference `json:"tlsSecretRef"`
+ UserAccess UserAccess `json:"userAccess"`
+ AdminSecretRef corev1.SecretReference `json:"adminSecretRef"`
+ TLSSecretRef corev1.SecretReference `json:"tlsSecretRef"`
}
^ ``AdminSecretRef`` is a secret reference containing admin credentials
required to start the kopia repository server
+
^ ``TLSSecretRef`` is a TLS secret reference for kopia client and server communication
+
^ ``UserAccess`` contains username and password secret reference required
- for creating kopia respository server users.
-
+ for creating kopia repository server users.
+
.. code-block:: go
:linenos:
type UserAccess struct {
- UserAccessSecretRef corev1.SecretReference `json:"userAccessSecretRef"`
- Username string `json:"username"`
+ UserAccessSecretRef corev1.SecretReference `json:"userAccessSecretRef"`
+ Username string `json:"username"`
}
- ``Status`` field in ``RepositoryServer`` CR is used by kanister controller
- to propogate server's status to the client. It is defined as:
+ to propagate server's status to the client. It is defined as:
.. code-block:: go
:linenos:
type RepositoryServerStatus struct {
- Conditions []Condition `json:"conditions,omitempty" patchStrategy:"merge" patchMergeKey:"type"`
- ServerInfo ServerInfo `json:"serverInfo,omitempty"`
- Progress RepositoryServerProgress `json:"progress"`
+ Conditions []Condition `json:"conditions,omitempty" patchStrategy:"merge" patchMergeKey:"type"`
+ ServerInfo ServerInfo `json:"serverInfo,omitempty"`
+ Progress RepositoryServerProgress `json:"progress"`
}
+
- ``Progress`` is populated by controller with 3 values
^ ``ServerReady`` represents the ready state of the repository server and
the pod which runs the proxy server
- ^ ``ServerStopped`` represents that the controller got an error while
+
+ ^ ``ServerStopped`` represents that the controller got an error while
starting the repository server
- ^ ``ServerPending`` represents that repository server is yet to be started completely
+
+ ^ ``ServerPending`` represents that repository server is yet to be started completely
- ``ServerInfo`` is populated by the kanister controller with
-the server details that client requires to connect to the server.
+ the server details that client requires to connect to the server
.. code-block:: go
:linenos:
type ServerInfo struct {
- PodName string `json:"podName,omitempty"`
- ServiceName string `json:"serviceName,omitempty"`
+ PodName string `json:"podName,omitempty"`
+ ServiceName string `json:"serviceName,omitempty"`
}
^ ``PodName`` is the name of pod created by controller for kopia repository server
-^ ``ServiceName`` is the name of the kubernetes service created by the controller
+
+^ ``ServiceName`` is the name of the Kubernetes service created by the controller
which contains the connection details for repository server
@@ -596,12 +615,14 @@ As a reference, below is an example of a Repository Server
namespace:
username:
+.. _repository_Server_secrets:
+
Repository Server Secrets
=========================
Kanister controller needs the following secrets to be created for starting the kopia
repository server successfully. The secrets are referenced in the ``RepositoryServer``
-CR as described in :ref:`RepositoryServer`
+CR as described in :ref:`RepositoryServer`
Location Storage Secret
-----------------------
@@ -610,7 +631,8 @@ This secret stores the sensitive details of the location where the kopia
repository is created. This secret is referenced by ``spec.storage.secretRef``
field in repository server CR
-The ``data.type`` field can have following values ``s3``, ``gcs`` , ``azure``, ``file-store``
+The ``data.type`` field can have following values ``s3``, ``gcs``,
+``azure``, ``file-store``
.. code-block:: yaml
:linenos:
@@ -638,11 +660,11 @@ The ``data.type`` field can have following values ``s3``, ``gcs`` , ``azure``, `
claimName:
Location Credentials Secret
-------------------
+---------------------------
Following is the secret to be used for Azure, AWS and GCS storage credentials.
This secret is referenced by ``spec.storage.credentialSecretRef`` in repository server
-CR
+CR
- ``AWS S3``
@@ -671,11 +693,11 @@ CR
apiVersion: v1
kind: Secret
metadata:
- name: az-loc-creds
+ name: s3-loc-creds
namespace:
- type: secrets.kanister.io/azure
+ type: secrets.kanister.io/aws
data:
- # required: base64 encoded value for account with proper permissions for the bucket
+ # required: base64 encoded value for account with proper permissions for the bucket
azure_storage_account_id:
# required: base64 encoded value for the key corresponding to the account above
azure_storage_key:
@@ -683,24 +705,24 @@ CR
# Acceptable values are AzureCloud, AzureChinaCloud, AzureUSGovernment, AzureGermanCloud
azure_storage_environment:
- - ``GCS``
+- ``GCS``
.. code-block:: yaml
- :linenos:
-
- apiVersion: v1
- kind: Secret
- metadata:
- name: gcs-loc-creds
- namespace:
- type: secrets.kanister.io/gcp
- data:
- # required: base64 encoded value for project with proper permissions for the bucket
- project-id:
- # required: base64 encoded value for the SA with proper permissions for the bucket.
- # This value is base64 encoding of the service account json file when
- # creating a new service account
- service-account.json:
+ :linenos:
+
+ apiVersion: v1
+ kind: Secret
+ metadata:
+ name: gcs-loc-creds
+ namespace:
+ type: secrets.kanister.io/gcp
+ data:
+ # required: base64 encoded value for project with proper permissions for the bucket
+ project-id:
+ # required: base64 encoded value for the SA with proper permissions for the bucket.
+ # This value is base64 encoding of the service account json file when
+ # creating a new service account
+ service-account.json:
Repository Password Secret
@@ -710,6 +732,7 @@ is referenced by ``spec.repository.passwordSecretRef`` in repository server CR
.. code-block:: yaml
:linenos:
+
apiVersion: v1
kind: Secret
metadata:
@@ -743,8 +766,8 @@ TLS Secret
----------
This secret store TLS sensitive data used for kopia client server communication.
-It is in standard ``kubernetes.io/tls`` format. It is referenced by ``spec.server.tlsSecretRef`` in
-repository server CR
+It is in standard ``kubernetes.io/tls`` format. It is referenced by
+``spec.server.tlsSecretRef`` in repository server CR
.. code-block:: yaml
:linenos:
@@ -764,12 +787,12 @@ repository server CR
Repository Server User Access Password Secret
---------------------------------------------
-The Kopia repository client needs an access username and password for authentication to
+The Kopia repository client needs an access username and password for authentication to
connect to kopia repository server
Kopia client needs user in the format ``@`` . The username is same
-for all the clients which is specified in ``spec.server.UserAccess.username`` of
-the ``RepositoryServer`` CR. The password and hostname is provided in the form of
+for all the clients which is specified in ``spec.server.UserAccess.username`` of
+the ``RepositoryServer`` CR. The password and host name is provided in the form of
a secret as shown below
.. code-block:: yaml
diff --git a/docs/index.rst b/docs/index.rst
index 40274e9a39..4f62c5f9e6 100644
--- a/docs/index.rst
+++ b/docs/index.rst
@@ -21,7 +21,7 @@ and easy to install, operate and scale.
overview
install
- tutorial
+ kanister_tutorial
architecture
tasks
tooling
diff --git a/docs/install.rst b/docs/install.rst
index 08c1026b32..97b839dcdb 100644
--- a/docs/install.rst
+++ b/docs/install.rst
@@ -103,19 +103,22 @@ like below:
--set bpValidatingWebhook.tls.caBundle=$(cat /path/to/ca.pem | base64 -w 0) \
--set bpValidatingWebhook.tls.secretName=tls-secret
+.. _deploying_repo_server_controller:
Deploying Kopia Repository server controller
============================================
-Kopia Repository server controller is not enabled by default. It can be deployed by setting the
-`repositoryServerController.enabled` value as shown below
+Kopia Repository server controller is not enabled by default. It can be
+deployed by setting the `repositoryServerController.enabled` value as
+shown below
.. substitution-code-block:: bash
helm upgrade --install kanister kanister/kanister-operator --namespace kanister --create-namespace \
--set repositoryServerController.enabled=true
-This will create another container in the kanister pod for kopia repository server controller.
+This will create another container in the kanister pod for kopia
+repository server controller.
Building and Deploying from Source
diff --git a/docs/kanister_tutorial.rst b/docs/kanister_tutorial.rst
index 8b050a3ed6..ab64d23802 100644
--- a/docs/kanister_tutorial.rst
+++ b/docs/kanister_tutorial.rst
@@ -5,5 +5,5 @@ Tutorials
.. toctree::
:maxdepth: 1
- tasks/tutorial.rst
- tasks/tutorial_with_repositoryserver.rst
\ No newline at end of file
+ tutorials/tutorial.rst
+ tutorials/tutorial_with_repositoryserver.rst
diff --git a/docs/overview.rst b/docs/overview.rst
index 3114077f0a..44d7564d4b 100644
--- a/docs/overview.rst
+++ b/docs/overview.rst
@@ -35,7 +35,7 @@ Getting Started
Follow the instructions in the :ref:`install` section to get Kanister up and
running on your Kubernetes cluster. Then see Kanister in action by going through
-the walkthrough under :ref:`tutorial`.
+the walkthrough under :ref:`tutorials`.
The :ref:`architecture` section provides architectural insights into how things
work. We recommend that you take a look at it.
diff --git a/docs/tutorials/tutorial_with_repositoryserver.rst b/docs/tutorials/tutorial_with_repositoryserver.rst
index db783348d7..10196a7ef5 100644
--- a/docs/tutorials/tutorial_with_repositoryserver.rst
+++ b/docs/tutorials/tutorial_with_repositoryserver.rst
@@ -1,9 +1,9 @@
Using Kopia Repository Server as Data Mover in Blueprint
********************************************************
-This tutorial will demonstrate the use of Kopia to copy/restore backups
-to a kopia repository. We will be using kanister functions
-that use Kopia repository Server as datamover in the blueprint. For more documentation
+This tutorial will demonstrate the use of Kopia to copy/restore backups
+to a kopia repository. We will be using kanister functions
+that use Kopia repository Server as data mover in the blueprint. For more documentation
on kanister functions and blueprints see :ref:`architecture` ,
:ref:`kanister functions` respectively
@@ -24,7 +24,8 @@ Prerequisites
* docker
* Kopia repository server controller should be deployed along with Kanister controller
-See :ref:`Deploying Kopia Repository server controller`
+ Refer
+ :ref:`Deploying Kopia Repository server controller `
* Access to s3 bucket and credentials
@@ -78,19 +79,21 @@ application is installed in the ``default`` namespace.
volumes:
- name: data
persistentVolumeClaim:
- claimName: time-log-pvc
+ claimName: time-log-pvc
EOF
Starting Kopia Repository Server
================================
-Since we will be using kopia data mover to copy/restore the backups to the location storage,
-we need to start the Kopia repository Server. To know more about kopia repository server,
-see :ref:`Kopia Repository Server Controller`
+Since we will be using kopia data mover to copy/restore the backups to the location
+storage, we need to start the Kopia repository Server. To know more about kopia
+repository server, refer :ref:`architecture `
-The repository server controller requires Repository Server custom resource to be created to
-start the server. To understand more about this custom resource, see :ref:`architecture`.
+The repository server controller requires Repository Server custom resource to
+be created to start the server. To understand more about this custom resource,
+see :ref:`architecture`.
+.. _creating_kopia_repository:
Creating a Kopia Repository
---------------------------
@@ -100,14 +103,15 @@ The kopia repository needs to be created before we start the repository server.
You can create it as shown below
.. code-block:: bash
- $ kopia --log-level=error --config-file=/tmp/kopia-repository.config
- --log-dir=/tmp/kopia-cache repository create --no-check-for-updates
- --cache-directory=/tmp/cache.dir --content-cache-size-mb=0 --metadata-cache-size-mb=500
- --override-hostname=timelog.app --override-username=kanisterAdmin s3
- --bucket=test-bucket
+
+ $ kopia --log-level=error --config-file=/tmp/kopia-repository.config
+ --log-dir=/tmp/kopia-cache repository create --no-check-for-updates
+ --cache-directory=/tmp/cache.dir --content-cache-size-mb=0 --metadata-cache-size-mb=500
+ --override-hostname=timelog.app --override-username=kanisterAdmin s3
+ --bucket=test-bucket
--prefix=/test/repo-controller
- --region=us-east-1
- --access-key=
+ --region=us-east-1
+ --access-key=
--secret-access-key=
To know more about how to create repository refer `kopia documentation
@@ -117,26 +121,35 @@ To know more about how to create repository refer `kopia documentation
Creating Secrets
----------------
-Please see :ref:`architecture` to know the secrets that needs to be created for repository server
+Please see :ref:`architecture` to know the secrets that needs to be created for
+repository server
- ``Creating TLS secret``
+
.. code-block:: bash
+
$ kubectl create secret tls repository-server-tls-cert --cert=/path/to/certificate.pem --key=/path/to/key.pem -n kanister
-
+
- ``Creating Repository Server User Access Secret``
.. code-block:: bash
+
$ kubectl create secret generic repository-server-user-access --type='secrets.kanister.io/kopia-repository/serveruser' -n kanister
- ``Creating Repository Server Admin Secret``
+
.. code-block:: bash
+
$ kubectl create secret generic repository-server-admin --type='secrets.kanister.io/kopia-repository/serveradmin' -n kanister --from-literal=username=admin@testpod1 --from-literal=password=test1234
- ``Creating Repository Password Secret``
+
.. code-block:: bash
+
$ kubectl create secret generic repository-pass --type='secrets.kanister.io/kopia-repository/password' -n kanister --from-literal=repo-password=test1234
- ``Creating Storage Location Secret``
+
The secret should have same values for ``bucket``, ``endpoint``, ``region`` fields that
we have used while creating kopia repository
@@ -160,10 +173,11 @@ Please see :ref:`architecture` to know the secrets that needs to be created for
# optional: specified in case of S3-compatible stores
endpoint:
# required, if supported by the provider
- region:
+ region:
EOF
- ``Creating Storage Location Credentials Secret``
+
.. code-block:: yaml
$ cat <
EOF
+.. _creating_repo_server_CR:
+
Creating Repository Server custom resource
------------------------------------------
Once the secrets are created, we need to create a repository Server CR having references
-to above created secrets. More details of the repository server CR
+to above created secrets. More details of the repository server CR
can be found at :ref:`architecture`
-We have to make sure that we use the same values for field,
+We have to make sure that we use the same values for field,
``spec.repository.username`` , ``spec.repository.hostname`` in the CR that we used while
-creating the repository in section :ref:`Creating a Kopia Repository`
+creating the repository in section :ref:`Creating a Kopia Repository `
-``--prefix`` field's value is a combination of prefix specified in `spec.data.path` field of
-location secret and sub-path provided in ``spec.repository.RootPath`` field of Reposiotry
-server CR
+``--prefix`` field's value is a combination of prefix specified in `spec.data.path`
+field of location secret and sub-path provided in ``spec.repository.RootPath``
+field of Repository server CR.
+
+``spec.data.path`` field of location storage secret ``s3-location`` appended
+with ``spec.repository.RootPath`` in the repository Server CR combined together
+should match the``--prefix`` field of the command used to create repository as
+specified in section :ref:`Creating a Kopia Repository `
-``spec.data.path`` field of location storage secret ``s3-location`` appended with ``spec.repository.RootPath``
-in the repository Server CR combined together should match the``--prefix`` field of the
-command used to create repository as specified in section :ref:`Creating a Kopia Repository`
-
.. code-block:: yaml
@@ -238,16 +255,16 @@ command used to create repository as specified in section :ref:`Creating a Kopia
EOF
-Once the Repository Server is created, you will see a repository server pod and a service exposing the
-the kopia repository server created in kanister namespace.
+Once the Repository Server is created, you will see a repository server pod and
+a service exposing the kopia repository server created in ``kanister`` namespace.
.. code-block:: bash
- $ kubectl get pods,svc -n kanister
+ $ kubectl get pods,svc -n kanister
NAME READY STATUS RESTARTS AGE
pod/kanister-kanister-operator-5b7dfbf97b-5j5p5 2/2 Running 0 33m
pod/repo-server-pod-4tjcw 1/1 Running 0 2m13s
-
+
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/kanister-kanister-operator ClusterIP 10.96.197.93 443/TCP 33m
service/repo-server-service-rq2pq ClusterIP 10.96.127.153 51515/TCP 2m13s
@@ -256,7 +273,7 @@ To see if the server started successfully, you can check the status of
the server using following command
.. code-block:: bash
-
+
$ kubectl get repositoryservers.cr.kanister.io kopia-repo-server -n kanister -oyaml
apiVersion: cr.kanister.io/v1alpha1
kind: RepositoryServer
@@ -321,19 +338,22 @@ into the specified Function.
For more on CustomResources in Kanister, see :ref:`architecture`.
- The Blueprint we'll create has a two actions called ``backup``
-and ``restore``. The action ``backup`` has a single phase named ``backupToS3``. ``backupToS3`` invokes the
-Kanister function ``BackupDataUsingKopiaServer`` that uses kopia repository server to copy backup
-data to s3 storage. The action ``restore`` uses two kanister functions ``ScaleWorkload`` and
-``RestoreDataUsingKopiaServer``. ``ScaleWorkload`` function scales down the timelog application
-before restoring the data. ``RestoreDataUsingKopiaServer`` restores data using kopia repository server
-form s3 storage.
+The Blueprint we'll create has a two actions called ``backup``
+and ``restore``. The action ``backup`` has a single phase named ``backupToS3``.
-For more information of kanister function refer :doc:`Kanister's parameter templating `.
+``backupToS3`` invokes the Kanister function ``BackupDataUsingKopiaServer``
+that uses kopia repository server to copy backup data to s3 storage. The action
+``restore`` uses two kanister functions ``ScaleWorkload`` and ``RestoreDataUsingKopiaServer``.
+``ScaleWorkload`` function scales down the ``timelog`` application before restoring the data.
+``RestoreDataUsingKopiaServer`` restores data using kopia repository server form
+s3 storage.
-We are using output artifacts here to store the path of our data in s3 and snapshot ID that
-that will be used as ``backupIdentifier`` while performing restore. To know more about
-artifacts you can refer :ref:`tutorial`.
+For more information of kanister function refer
+:doc:`Kanister's parameter templating `.
+
+We are using output artifacts here to store the path of our data in s3 and
+snapshot ID that that will be used as ``backupIdentifier`` while performing restore.
+To know more about artifacts you can refer :ref:`tutorials`.
Blueprint
---------
@@ -407,31 +427,35 @@ each time you want to execute any Kanister actions. The ActionSet contains all
the runtime information the controller needs during execution. It may contain
multiple actions, each acting on a different Kubernetes object. The ActionSet
we're about to create in this tutorial specifies the ``time-logger`` Deployment we
-created earlier and selects the ``backup`` action inside our Blueprint.
+created earlier and selects the ``backup`` action inside our Blueprint.
+
+Add some data in the time logger app.
-Add some data in the time logger app
.. code-block:: bash
+
kubectl exec -it time-logger-6d89687cbb-bmdj8 -n default -it sh
sh-5.1# cd /var/log/
sh-5.1# ls
time.log
- sh-5.1# echo "hello world" >> test.log
- sh-5.1# cat test.log
+ sh-5.1# echo "hello world" >> test.log
+ sh-5.1# cat test.log
hello world
ActionSet
---------
.. code-block:: bash
+
# Create action set using the blueprint created in above step
$ kanctl create actionset --action backup --namespace kanister --blueprint time-log-bp --deployment default/time-logger --repository-server kanister/kopia-repo-server
actionset actionset backup-rlcnp created
-``--repository-server`` flag is used to provide the reference to the repository server CR that we created
-in step :ref:`Creating Repository Server custom resource`. Since the details related to kopia repository server and
-the secrets are present in the CR, the blueprint will be able to read these details using
-template parameters and will perform backup using kopia repository server
+``--repository-server`` flag is used to provide the reference to the repository server
+CR that we created in step :ref:`Creating Repository Server custom resource `. Since
+the details related to kopia repository server and the secrets are present in the CR,
+the blueprint will be able to read these details using template parameters and will
+perform backup using kopia repository server.
.. code-block:: bash
@@ -448,13 +472,14 @@ template parameters and will perform backup using kopia repository server
Lets delete the date from ``timelogger`` app.
.. code-block:: bash
- kubectl exec -it time-logger-6d89687cbb-bmdj8 -n default -it sh
+
+ $ kubectl exec -it time-logger-6d89687cbb-bmdj8 -n default -it sh
sh-5.1# cd /var/log/
sh-5.1# ls -lrt
total 12
-rw-r--r-- 1 root root 12 Jun 5 06:22 test.log
-rw-r--r-- 1 root root 7308 Jun 5 06:26 time.log
- sh-5.1# rm -rf test.log
+ sh-5.1# rm -rf test.log
sh-5.1# ls -lrt
total 8
-rw-r--r-- 1 root root 7482 Jun 5 06:26 time.log
@@ -463,14 +488,16 @@ Lets delete the date from ``timelogger`` app.
Lets perform restore now, by using ``restore`` action from the ``time-log-bp`` blueprint
.. code-block:: bash
- kanctl --namespace kanister create actionset --action restore --from "backup-rlcnp" --repository-server kanister/kopia-repo-server
+
+ $ kanctl --namespace kanister create actionset --action restore --from "backup-rlcnp" --repository-server kanister/kopia-repo-server
actionset restore-backup-rlcnp-g5h65 create
We can see if the restore is successful by describing the actionset
.. code-block:: bash
- $kubectl describe actionsets.cr.kanister.io restore-backup-rlcnp-g5h65 -n kanister
-
+
+ $ kubectl describe actionsets.cr.kanister.io restore-backup-rlcnp-g5h65 -n kanister
+
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
@@ -483,11 +510,12 @@ We can see if the restore is successful by describing the actionset
Normal Ended Phase 3s Kanister Controller Completed phase bringupPod
Normal Update Complete 2s Kanister Controller Updated ActionSet 'restore-backup-rlcnp-g5h65' Status->complete
-Lets check if the data was restored successfully. We should see the ``time.log`` file that was removed
-before performing restore
+Lets check if the data was restored successfully. We should see the ``time.log``
+file that was removed before performing restore
.. code-block:: bash
- kubectl exec -it time-logger-6d89687cbb-pv5x6 -n default -it sh
+
+ $ kubectl exec -it time-logger-6d89687cbb-pv5x6 -n default -it sh
sh-5.1# ls -lrt /var/log
total 16
-rw-r--r-- 1 root root 12 Jun 5 06:22 test.log