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