Nik Paushkin

The billing model of traditional cloud instances, where costs are tied to capacity rather than usage, often leads to inefficiency and wasted expenditure. Puzl introduces a game-changing approach — Zero Idle costs, ensuring organizations only pay for resources (CPU and memory, in particular) their workloads actually utilized, aligning perfectly with FinOps principles.

## The Burden of Idle Resources

For years, the cloud industry has grappled with the challenge of idle resources. Companies would provision infrastructure based on peak demand forecasts, resulting in significant unused capacity during non-peak times. This approach, while safe, is inherently inefficient, as businesses incur expenses for resources that lie dormant. In the FinOps framework, such inefficiencies are more than just a cost issue; they represent a misalignment with the principle of matching spend to actual business value.

## Zero Idle: A Financially Savvy Approach

puzl.cloud disrupts this by introducing a Zero Idle model that pivots from paid allocation of CPU and memory to paid actual consumption of them. This model allows organizations to set precise resource consumption limits, ensuring that they only pay for the processing time and memory that their workloads actively consume. 

Instead of committing funds to reserved, yet often underutilized, resources, Puzl provides burstable compute resources that intelligently adapt during the workload's runtime, dynamically scaling up and down with its demands. This real-time allocation and de-allocation of resources means costs directly reflect usage, minimizing pre-allocation expenses.

## Enhanced Cross-Functional Collaboration

Puzl's approach also fosters enhanced collaboration between finance, operations, and development teams. Developers can innovate freely, knowing that the infrastructure will respond to their needs without incurring unnecessary costs. Operations teams benefit from the reduced complexity of managing infrastructure, and finance teams gain clearer insights into how cloud spend drives business value. This cross-functional harmony is the cornerstone of effective FinOps practices.

## Strategic Advantage in a Competitive Landscape

In a competitive market, the strategic advantage provided by Zero Idle cannot be overstated. Organizations that leverage Puzl's model can reinvest the savings from eliminated idle costs into innovation, customer experience, and growth initiatives. This efficient resource utilization becomes a catalyst for business agility and competitive differentiation.

Zero Idle is a new paradigm that redefines cloud efficiency for FinOps. It's an alignment of technology and business value, ensuring cloud spend drives growth rather than just being a cost of business.

## Expanding on Puzl's Vision

Recently, we introduced [GitLab Pipelines service]({{process.env.REACT_APP_FRONTEND_URL}}/products/ci-runners-for-gitlab). This is an embodiment of our Zero Idle paradigm, designed to make the most efficient use of cloud resources. This service exemplifies Puzl's commitment to providing managed services that harness the power of Zero Idle across the board. 

Our vision extends beyond individual services; we're creating a comprehensive cloud ecosystem where every application, from continuous integration pipelines to real-time data analytics, operates with unmatched financial and operational efficiency. Puzl is not just optimizing one aspect of cloud infrastructure but reimagining the entire cloud experience to align with the FinOps imperative of deriving maximum value from every cloud investment.

The billing model of traditional cloud instances, where costs are tied to capacity rather than usage, often leads to inefficiency and wasted expenditure. Puzl introduces a game-changing approach — Zero Idle costs, ensuring organizations only pay for resources (CPU and memory, in particular) their workloads actually utilized, aligning perfectly with FinOps principles.

Embracing Zero Idle: The New Paradigm in FinOps Efficiency

Puzl Team

This article shows  how to deploy your web application (HTTP server), and securely expose it to the Internet over HTTPS protocol.

## Requirements
1. [kubectl](https://kubernetes.io/docs/tasks/tools/) and [Helm](https://helm.sh/docs/intro/install/) must be installed on your computer.
If you’re using Puzl, you may find the personalised config, necessary to set up kubectl, in the API section of the [Dashboard](https://ui.auth.puzl.cloud/sign-up/).
2. Kubernetes cluster must support Services with `loadBalancer` type and have [cert-manager](https://cert-manager.io/docs/installation/kubernetes/) installed.
On Puzl, both load balancers and cert-manager are already available in your free Kubernetes namespace out of the box.
3. Your application must be containerized (packed in a Docker image), pushed to a Docker registry, and support HTTP protocol. 
The application itself does not have to support SSL or TLS: it will be running behind the Nginx ingress controller connected by HTTP, so you don’t need to tune anything in your code.

**‼︎ Caution**: Performing the following steps will result in requesting computing resources from the Kubernetes cluster.

## Setup ingress controller

1. Deploy [NGINX Ingress Controller](https://kubernetes.github.io/ingress-nginx) using Helm, and create a load balancer with a dedicated IP address, which is allocated automatically if you use Puzl.

```bash
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update

helm install <controller_name> ingress-nginx/ingress-nginx \
  --namespace <namespace_name> \
  --version 4.2.5 \
  --set controller.image.registry=k8s.gcr.io \
  --set controller.image.digest="" \
  --set controller.ingressClass=<ingress_name> \
  --set controller.ingressClassByName=true \
  --ser controller.ingressClassResource.enabled=false \
  --set controller.replicaCount=2 \
  --set controller.scope.enabled=true \
  --set controller.resources.requests.cpu=100m \
  --set controller.resources.requests.memory=128Mi \
  --set controller.resources.limits.cpu=1000m \
  --set controller.resources.limits.memory=1024Mi \
  --set controller.admissionWebhooks.enabled=false \
  --set controller.nodeSelector="" \
  --set controller.service.appProtocol=false \
  --set rbac.create=false \
  --set podSecurityPolicy.enabled=false \
  --set serviceAccount.create=false \
  --set serviceAccount.name=user \
  --atomic \
  --timeout 600s
```

* `<controller_name>` — unique name for the controller
* `<namespace_name>` — if you’re using Puzl, you’ll find it in the API section in your Puzl Dashboard
* `controller.ingressClass=<ingress_name>` — class name for ingress object must be unique.
* `serviceAccount.name=user` — name of the account with the permissions to access API, `user` is your service account name on Puzl.

The following flags are relevant in case you’re using Puzl:
* `controller.replicaCount=1`
* `controller.scope.enabled=true` — tell the controller to look for ingress resources only in your namespace.
* `controller.admissionWebhooks.enabled=false`
* `rbac.create=false` — do not give excess permissions to create roles and role bindings
* `podSecurityPolicy.enabled=false`
* `serviceAccount.create=false`

After performing the step, you can get Pod and Service using kubectl or you should see a Pod and a TCP/UDP Balancer in your dashboard if you’re using Puzl.

In case of troubles check out [NGINX Ingress Controller Troubleshooting](https://kubernetes.github.io/ingress-nginx/troubleshooting/).

## Get external IP of load balancer

1. To get IP, get list of Kubernetes Services in your namespace and find `EXTERNAL-IP`.

```bash
kubectl -n <namespace_name> get service <controller_name>-ingress-nginx-controller
```

2. Check that IP is accessible from outside.

```bash
curl <external_ip>
```

Expected response:
```html
<html>
<head><title>404 Not Found</title></head>
<body>
<center><h1>404 Not Found</h1></center>
<hr><center>nginx</center>
</body>
</html>
```

3. Assuming that you already own a custom domain, create DNS ‘A’ record to match your domain or its subdomain to a given IP address.

## Create cert issuer to request TLS certificate from Let’s Encrypt

Kubernetes can be extended with a native certificate management controller — [cert-manager](https://cert-manager.io/docs/). It can help with issuance of TLS certificates from various providers like Let’s Encrypt, a signing key pair or self-signed. At the moment Puzl supports only [letsencrypt](https://letsencrypt.org) certificates.

At this step you need a [cert-manager](https://cert-manager.io/docs/installation/kubernetes/) installed.

Signed certificates are generated by a special Kubernetes resource — [Issuer](https://cert-manager.io/docs/concepts/issuer/). We use ACME type of Issuer — Automated Certificate Management Environment (ACME). A website with TLS certificate backed by ACME Issuer is trusted by most client’s web browsers by default.

1. Describe the Issuer configuration in a `spec.yaml`.

```yaml
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: letsencrypt
  namespace: <namespace_name>
spec:
  acme:
    # The ACME server URL
    server: https://acme-v02.api.letsencrypt.org/directory
    # On January 11th 2021, Let’s Encrypt will change over to using its own ISRG Root CA.
    preferredChain: "ISRG Root X1"
    # Email address used for ACME registration
    email: <your_email>
    # Name of a secret used to store the ACME account private key
    privateKeySecretRef:
      name: <secret_name>
    # Enable the HTTP-01 challenge provider
    solvers:
    - http01:
        ingress:
          # ingressClass
          class: <ingress_name>
```

Choose any free `<secret_name>`, the signed certificate will be stored as a Secret object.

See [other options of solvers](https://cert-manager.io/docs/configuration/acme/dns01/).

2. Apply the configuration via `kubectl`.

```bash
kubectl apply -f spec.yaml
```

The signed certificate is now stored as a Secret named  `<secret_name>`.

## Run your web application in Kubernetes

In the code snippet below we’re deploying an [example sanic server](https://github.com/puzl-ee/example-sanic-server)  by creating a Deployment with 1 replica and Service for it.

However, you can use Docker image with any web server (Apache, built-in PHP, etc.) and tune the configuration up to your requirements.

1. Describe your app configuration in a `.yaml` file.

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: example-sanic-server
  namespace: <namespace_name>
  labels:
    app: example-sanic-server
spec:
  replicas: 1
  selector:
    matchLabels:
      app: example-sanic-server
  template:
    metadata:
      labels:
        app: example-sanic-server
    spec:
      containers:
      - name: example-sanic-server
        # Path to a Docker image with your application
        image: puzlcloud/example-sanic-server:0.2.0
        resources:
          requests:
            memory: "256Mi"
            cpu: "100m"
          limits:
            memory: "256Mi"
            cpu: "100m"
        ports:
          # HTTP port which your server listens
          - containerPort: 1616

---
apiVersion: v1
kind: Service
metadata:
  name: example-sanic-server-service
  namespace: <namespace_name>
spec:
  selector:
    app: example-sanic-server
  ports:
    - protocol: TCP
      port: 80
      # The same HTTP port of your server
      targetPort: 1616
```

2. Apply previously created `.yaml` to deploy your app.

```bash
kubectl apply -f spec.yaml
```

## Create ingress object

Ingress is used to expose HTTPS routes from outside of the cluster to services within the cluster (by default Kubernetes isolates Pods from the external world)

1. Describe ingress object in a `.yaml`.

```yaml
apiVersion: networking.k8s.io/v1 
kind: Ingress
metadata:
  name: example-sanic-server
  namespace: <namespace_name>
  annotations:
    kubernetes.io/ingress.class: <ingress_name>   
    cert-manager.io/issuer: letsencrypt
spec:
  rules:
  - host: <your_domain>
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: example-sanic-server-service
            port:
              number: 80
  tls:
  - hosts:
    - <your_domain>
    secretName: <certificate_name>
```

`<certificate_name>` — must be different from a Secret name used for the Issuer.

2. Apply the configuration via `kubectl`.

```bash
kubectl apply -f spec.yaml
```

You should see a Pod launched to obtain a certificate. This process may take a few minutes. To check its status run:

```bash
kubectl -n <namespace_name> get certificate <certificate-name>
```

`READY` should be `true`.

To check that our web server is working open in the browser: `https://<your_domain>/swagger/`

![Check that web server is working](/images/assets/blog/posts/https-tls-cert-manager/run-https-server-with-lets-encrypt-certificate-using-kubernetes-cert-manager-gjws.jpg)

How to deploy your web application, and securely expose it to the Internet over HTTPS with no code changes.

Deploy web app with Let's Encrypt certificate using Kubernetes cert-manager

<DeprecationMessage>

<DeprecationMessageTitle>We've made some exciting updates</DeprecationMessageTitle>

This article covers the old GitLab runner setup on puzl.cloud. We're thrilled to announce our new SaaS Runners for GitLab, arguably the world's fastest and most cost-effective solution for running GitLab pipelines. 

Dive in and see why it's a game-changer, all **without any code adjustments** on your end!

<Button colorScheme='gradient' as='a' href='{{process.env.REACT_APP_FRONTEND_URL}}/products/ci-runners-for-gitlab' className='message-action'>Get free trial</Button>

</DeprecationMessage>


In this article, we will show how to easily deploy your application to Kubernetes on the example of gitlab.com and GitLab Runner, why it might be better to install your own CI runner, and how Puzl helps you to reduce costs and headache in this case.

### Why set up your own GitLab runner

[GitLab Runner](https://docs.gitlab.com/ee/ci/runners/README.html) allows you to run GitLab pipelines and returns the results of the pipeline work back to GitLab. You can even [run any application and databases](https://docs.gitlab.com/ce/ci/services/) in your pipelines.

Even though popular git-providers offer free pipeline minutes, there are several reasons why you should consider having your own CI runner.

Since Puzl provides you **free direct access** to your [own cloud Kubernetes namespace](/blog/puzl-the-first-pure-kubernetes-cloud), you can create [burstable Pods]({{env.REACT_APP_DOCS}}/cloud-kubernetes/computing-resources#pricing-burstable-example) and pay only for resources utilised by your running pipelines based on the **pay-per-pod** model. It means that:

* Your pipeline on Puzl will be executed within a minimum possible amount of time because its resources won’t be limited. Shared cloud runners can not offer that flexibility.
* You will never exceed the free limit (Puzl has no free limit) and will never be switched to an overpriced tariff. Puzl offers fair, transparent and predictable pricing.

Starting from September 2020 GitLab [reduced the amount of free pipeline minutes](https://about.gitlab.com/releases/2020/09/01/ci-minutes-update-free-users/) from 2000 to 400. In case you need more, you will have to pay $10 for every 1000 minutes. Let’s calculate price of that 400 minutes on Puzl and why it might be better for you to pay for the first 400 minutes, than use shared cloud runners.

Let’s assume that your pipelines had been working for 7 hours (420 min) within a month and consumed precisely 4GB of RAM and 2vCPU during the whole period of work. In this case, the cost of the runner and all pipelines launched by it will be: 

* 1.28€ for the runner itself, which is working for the whole month non-stop and can serve thousands of pipelines;
* 0.039€ per hour for 7 hours of pipelines, which equals to 0.273€.

That makes 1.55€ per month, totaly. In fact, <span className='accent'>1.55€ are your maximum monthly costs in comparison with cloud pipeline minutes</span>. At the same time, Puzl saves you money if you use more than 400 pipeline minutes per month, and also Puzl saves you time on waiting for pipeline’ execution on shared runners.

### Why use Puzl instead of cloud instances 

* You don’t have to rent unnecessary cloud instances, that will be idle most of the time when no pipes are running.
* You don’t have to run benchmarks to estimate how many resources your pipeline consumes to rent cloud instance of suitable configuration.
* You don’t have to bother about scaling your cloud instances in case of a sharp increase in the number of pipelines run simultaneously: every new pipeline runs in a separate Kubernetes pod. It allows you to allocate resources flexibly and without sacrificing performance.

<div className="tip-box">
<div className="tip-box__header">Tip</div>

One of the most powerful aspects of Puzl is that your pipelines are running inside your isolated Kubernetes namespace. That means that you can interact with Kubernetes API directly from the code of a pipeline, which makes your GitLab pipelines an efficient automatisation tool.
</div>

# Install your own GitLab Runner in your Puzl Kubernetes namespace

We will use a small dummy HTTP server built with Python, to demonstrate GitLab Runner installation process.

#### Requirements:

-  Puzl’s [example sanic server](https://github.com/puzl-ee/example-sanic-server), where we have already set up deployment and build configuration:

    * [.gitlab-ci.yml](https://gitlab.com/puzlcloud/example-sanic-server/-/blob/master/.gitlab-ci.yml) - configuration of GitLab pipeline
    * [Dockerfile](https://gitlab.com/puzlcloud/example-sanic-server/-/blob/master/Dockerfile) - Docker Image to deploy our HTTP server. To build your Docker image, we recommend [Kaniko](https://github.com/GoogleContainerTools/kaniko): it allows you to safely build a Docker image from a Dockerfile, without using Docker daemon.
    * [example-sanic-server.yaml](https://gitlab.com/puzlcloud/example-sanic-server/-/blob/master/example-sanic-server.yaml) - simple deployment configuration for Kubernetes to run our server in Puzl cloud.

-  [Docker Hub](https://hub.docker.com/) account to push your built Docker Image.
-  [GitLab](https://gitlab.com) account.
-  [Puzl Cloud](/dashboard) account.

## Install the GitLab Runner app in Puzl cloud dashboard. 

1. Find GitLab Runner in the Marketplace section of your Puzl dashboard, press `Install`.
2. **Fill in Token and URL**: In your GitLab account, go to the **Project** > **Settings** > **CI/CD** > expand **Runners** section and copy token and the URL.

![Get Gitlab Runner token](/images/assets/blog/posts/gitlab-runner/get-gitlab-token.png)

3. Fill in the tag (e.g. `puzl-runner`, `puzl`) which you want to associate with the runner. Remember to put this tag to the tags section of your project’s [.gitlab-ci.yml](https://gitlab.com/puzlcloud/example-sanic-server/-/blob/master/.gitlab-ci.yml#L27) as well.
4. Press `Install` and get your runner up and running in a minute.

![Get Gitlab Runner token](/images/assets/blog/posts/gitlab-runner/install-gitlab-runner.gif)

5. To check that your runner is working, in the GitLab go to the **Project** > **Settings** > **CI/CD** > **Runners**.

![Check Gitlab Runner](/images/assets/blog/posts/gitlab-runner/check-runner-in-gitlab.png)

## Configure Runner on GitLab

Now, we need to configure GitLab project variables. Go to **Project** > **Settings** > **CI/CD** > **Variables **and add the following variables:

1. Set up **Docker credentials**: log in your Docker Hub account by cli with the command `docker login`. Get the contents of `~/.docker/config.json` and put it in the separate variable under the name `DOCKER_REGISTRY_CONFIG` (as it’s used in [.gitlab-ci.yml](https://gitlab.com/puzlcloud/example-sanic-server/-/blob/master/.gitlab-ci.yml#L10)). ⚠️ Set variable type as `File`.

  ⚠️ **Note**: your config should contain key `auth` like in the example below. All other keys are not required.

  ```json
{
    "auths": {
        "https://index.docker.io/v1/": {
            "auth": "a2N...JE="
        }
    }
}
  ```

  If there’s no `auth` key, you should remove the key `credsStore` from the generated config and do `docker login` again. This time `auth` key should be there.

2. If you need access to  k8s api from pipeline set variable with name `KUBERNETES_SERVICE_ACCOUNT_OVERWRITE` and value `user`.

3. Add the following files to your project: [Dockerfile](https://gitlab.com/puzlcloud/example-sanic-server/-/blob/master/Dockerfile), [example-sanic-server.yaml](https://gitlab.com/puzlcloud/example-sanic-server/-/blob/master/example-sanic-server.yaml), [.gitlab-ci.yml](https://gitlab.com/puzlcloud/example-sanic-server/-/blob/master/.gitlab-ci.yml) and wait for the pipeline to finish.

  Don’t forget to specify your DockerHub account name in the [.gitlab-ci.yml](https://gitlab.com/puzlcloud/example-sanic-server/-/blob/master/.gitlab-ci.yml#L14) script section instead of `puzlcloud`:

  ```yaml
  /.../
  build:
    script:
      - /kaniko/executor --context $CI_PROJECT_DIR
        --dockerfile $CI_PROJECT_DIR/Dockerfile
        --destination YOUR_DOCKERHUB_NAME/example-sanic-server:0.1.0
  /.../
  ```

  Do the same in  [example-sanic-server.yaml](https://gitlab.com/puzlcloud/example-sanic-server/-/blob/master/example-sanic-server.yaml#L19):

  ```yaml
  /.../
  spec:
        containers:
        - name: example-sanic-server
          image: YOUR_DOCKERHUB_NAME/example-sanic-server:0.1.0
  /.../
  ```

4. When the pipeline is finished, you will see Pod with example-sanic-server running on your Pod’s page.

![Check Gitlab Runner](/images/assets/blog/posts/gitlab-runner/installed-server-pod.png)

## Access your test server

Once your Pod is Running, you can access your HTTP server by an external port and a hostname, specified in the Network panel on the Pod’s page.

```
http://external_host:external_port/swagger
``` 

Port was created automatically from the config, specified in [example-sanic-server.yaml](https://gitlab.com/puzlcloud/example-sanic-server/-/blob/master/example-sanic-server.yaml#L22). Note, that such label is required to display the port in your Puzl Dashboard:

```yaml
/.../
metadata:
  labels: 
    example-sanic-server.puzl/Deployment: ""
/.../
```

![Add Gitlab Runner Variable](/images/assets/blog/posts/gitlab-runner/pod-network-access.png) 


How to install your own GitLab Runner to Kubernetes and why it might be better and cheaper than using 400 free cloud pipeline minutes

How to run your own GitLab CI Runner for 1.28€/mo and why it's worth a try

In this article, we’re considering several basic cases of running a Jupyter Notebook remote server with either classic or modern JupyterLab user interface. We'll show how easily you can run it entirely online and boost it with one or multiple [cloud GPUs](/gpu-cloud) using the appropriate Jupyter Notebook application on Puzl. 

## Simply run Jupyter Notebook

1. Go to your [Puzl dashboard](/dashboard) and open **Marketplace**, the section that allows you to run cloud native applications in a couple of clicks. There are not many applications in the Puzl Marketplace yet, so just click the **Jupyter Notebook** and press the **“Install”** button.

![puzl-cloud-marketplace](/images/assets/blog/posts/run-jupyter-in-30-sec/find-marketplace.gif)

2. Choose which user interface you prefer to install: classic Jupyter Notebook vs JupyterLab. Since the new generation JupyterLab UI has many more features, it is recommended and set by default.

3. Enter a password, which you will use to access your Jupyter Notebook interface after installation.

4. Choose the environment (Docker image) you need to run your Jupyter Notebook. If you use Jupyter for machine learning tasks, you can choose an image with Tensorflow or Pytorch or any other ML framework. Jupyter supports many runtimes (kernels) such as Python, R, etc. To run Jupyter Notebook with pre-installed R kernel use **"R notebook"** Docker image.

5. Optionally, you can configure the resources for your Jupyter Notebook server using advanced options. The lowest recommended amounts are 1 vCPU and 4GB of RAM, which are set by default. The hourly price for your cloud Jupyter Notebook app is calculated based on these amounts and is **0.023 EUR per hour** for the recommended minimum configuration.

6. Set the size of a fast NVMe based persistent volume, which you will use to store your datasets and results of the explorations. The volume will be created automatically. Please notice that the volume cost is calculated separately from the hourly price mentioned in point 5.

7. Finally press **“Install”**. Wait no more than 2 minutes, and your Jupyter Notebook will be started. You can open the user interface using a link provided on your running Jupyter Notebook application page.

![puzl-cloud-marketplace](/images/assets/blog/posts/run-jupyter-in-30-sec/install-jupyter.gif)

## Install Jupyter Notebook extensions in several clicks

1. All Puzl's Docker images contain the necessary dependencies to allow you to install Jupyter Notebook extensions using its graphical interface only. All the estensions you install are stored on the volume that you set in step 6 of the previous chapter.

![puzl-cloud-marketplace](/images/assets/blog/posts/run-jupyter-in-30-sec/install-jupyter-extension.gif)

<div> </div>

## Load your dataset first then run Jupyter Notebook with GPU

Most machine learning tasks require a large amount of data. If you would like to reduce your costs, you probably wouldn’t rent a lot of computing resources (CPU, RAM, GPU) for the time of data loading. For this case, Puzl gives you an ability to load your data first easily, and then request the amounts of CPU, RAM and GPU required for your computations.

1. To load data, you need to set up access to the volume. To do that, stop your Jupyter Notebook application, which has been launched in the first paragraph. Once your Jupyter Notebook server is stopped, the volume is freed. Now, you can access it via SSH using a pod with the smallest resources requests: 128MB of RAM and 0.1 vCPU only. 

2. To access the volume, go to the volume’s page and click the **“Setup SSH access”** button. Your pod with the SSH server will be ready in several seconds (don’t forget to add your SSH public key in the Security section). Once your pod is ready, you can connect to your volume via SSH and load data using scp, wget or rsync. See how to use rsync to transfer a large amount of data in [this article](/blog/transfer-files-over-ssh-with-rsync).

![puzl-cloud-marketplace](/images/assets/blog/posts/run-jupyter-in-30-sec/add-ssh-access.gif)

3. When you are done with data loading, just delete your SSH pod using the **“Delete Deployment”** button on the pod’s page. Once the pod is deleted, your volume is available to be mounted back to your Jupyter Notebook application.

4. Go to your Jupyter Notebook application page and click the **"Resume"** button. In the dialog pick the option **"Resume with different settings"**. When you will be redirected to the upgrade page, choose the volume, where you uploaded all necessary data from the picker of existing volumes. Then press **"Show advanced settings"** and choose the needed amount of GPUs. Finaly, press the green **"Upgrade"** button to run your Jupyter Notebook with GPU.

![puzl-cloud-marketplace](/images/assets/blog/posts/run-jupyter-in-30-sec/resume-jupyter.gif)

Now, your Jupyter Notebook is up and running with GPU and your data accessible in its interface.

### What’s next?

In the near future, we plan to implement pipelines to give you an ability to run your Jupyter Notebooks using CI/CD flow to organize the MLOps processes. For now, you can set up the pipelines yourself with our Gitlab runner application or using native Kubernetes API.

Also, we are going to provide configurable environments, which means that your Jupyter Notebook might be automatically built and launched with all necessary dependencies if you describe them.

How to run JupyterLab in cloud with GPU, without setting up virtual machines? Just install it in 1 click like a mobile app!

Running Jupyter Notebook in cloud with GPU in 30 seconds

Ekaterina Marova

As you probably know, SSH protocol can be used to upload files over an encrypted channel. Although transferring of large files can be interrupted by the loss of connection. 

To resolve this issue you could use rsync or “Remote Synchronization” — an efficient tool that synchronizes the content of two directories. It incrementally copies only new files or diffs of updated files, which results in significantly faster transfer time. These files may get compressed to further reduce the load on the network.

#### Requirements

1. SSH access to the remote server. 
2. Rsync must be installed on both systems: destination and the source. Puzl has rsync installed on its servers.
3. The user, who is running rsync, and the remote SSH user must have appropriate permissions to read and write files.

## Install rsync on your system

1. Pick suitable package manager.

On Debian based distributions (Ubuntu):

```
apt-get install rsync
```

On rpm-based distributions (Fedora, CentOS):

```
yum install rsync
```

On macOS:

```
brew install rsync
```

2. Check whether the installation was successful by running the following command, which prints rsync version.

```
rsync -version
```

On Windows there are several tools that enable rsync: 

- [Acrosync](https://acrosync.com/windows.html) — GUI client;
- [Cygwin](https://www.cygwin.com) — Posix runtime for WIndows, that ships rsync among other packages;
- Or you can enable Windows Subsystem for Linux (WSL), install a Linux distribution of your choice, and in this distribution, to run rsync. Check the guide on how to enable WSL in [official Microsoft documentation](https://docs.microsoft.com/en-us/windows/wsl/install-win10). Then to install rsync run: <br/>
```
sudo apt install rsync openssh-client
```

## Upload files

1. Rsync requires the source and the destination to be specified. 

The basic syntax is:

```
rsync {options} {source} {destination}
```

2. It's recommended to run the following script. The script is wrapped in a while loop, so the process will reconnect in case of failure.

```shell
while ! \
   rsync -aHxvh \
   --numeric-ids \
   --progress \
   -e "ssh -T -c aes256-gcm@openssh.com -o Compression=no -o StrictHostKeyChecking=no -x -p {EXTERNAL_PORT}" \
   {PATH_TO_YOUR_FILE_OR_DIRECTORY} {USERNAME}@{SERVER}:/{DESTINATION}; do sleep 1; done
```

If you’re using Puzl parameter's values would be the following:

- `{EXTERNAL_PORT}` — this port will be created for you when you request SSH access for your Volume or create a pod with SSH access. More on this later in the article.
- `{DESTINATION}` — for Volumes created by Puzl it is equal to `media/{VOLUME_NAME}` 
- `{USERNAME}` — ubuntu
- `{SERVER}` — eu-north-1.clusters.puzl.ee

Here we use some options meant to increase transfer speed:

- `-o Compression=no` — turns off SSH compression, compression slows down the transfer process;
- `-c aes256-gcm@openssh.com` — specifies a cypher algorithm. aes256 shows one of the best performances in [benchmarks](https://calomel.org/aesni_ssl_performance.html). You can run `openssl speed` to test the approximate performance of different algorithms on your hardware;
- `-x` — forbids running of graphic applications over SSH, thus facilitating the work of SSH server.

Other useful flags:

- `-a` or `--archive` — copies not only files but also preserves almost every connected data like permissions and modification time, enables recursion into directories as well;
- `-h` or `--human-readable` — outputs numbers in a more human-readable format;
- `--progress` — displays transfer times, as well as the name of the files and directories;
- `-T` — disables pseudo-tty allocation, because some servers could abort a transaction entirely if a text-terminal (tty) is requested;
- `-o StrictHostKeyChecking=no` — without this key if Pod restarts while loop is not finished, files transferring will abort. 

You can learn about other possible flags in [this rsync cheatsheet](https://linux.die.net/man/1/rsync).

3. Once the process is finished, verify that you have received your files on the destination server by connecting to the server and running.

```
ls -l
```

## How to setup SSH access if you are using Puzl

If you still don’t know what Puzl is, I recommend you to take a look at our previous article about the [Pure Kubernetes Cloud concept](/blog/puzl-the-first-pure-kubernetes-cloud).

1. Add SSH key to your account: go to the Security page of your Account and add SSH public key.

2. Setup SSH access to your Volume.

- If your Volume is not created yet, pick an option `Add SSH access` in the Volume creation form;
- If your Volume has been created already, you can set up access right on the Volume’s page.


 ![Setup SSH access in Puzl dashboard](/images/assets/blog/posts/transfer-files-over-ssh-with-rsync/puzl-dashboard-ssh-access-setup.png)
 
In both cases to set up SSH access a Pod will be created with minimal resource request: 128MB RAM and 0.1 vCPU. 

You will also see an external port created for you. Use this external port to connect by SSH or transfer files with rsync.

![Setup SSH access in Puzl dashboard](/images/assets/blog/posts/transfer-files-over-ssh-with-rsync/puzl-dashboard-ssh-access-setup-port.png)   

Step-by-step guide on how to upload files using SSH protocol and rsync tool for safe reconnect. 

How to transfer files over SSH with rsync

## What is a Cloud-Native Computing Platform?

A Cloud-Native Computing Platform is defined as a cloud environment composed of shared Kubernetes clusters. Here, users directly obtain access to their fully isolated Kubernetes namespaces, eliminating the need to manage virtual machines, cloud instances, or the Kubernetes cluster itself.

Within a Cloud-Native Computing Platform, users have access to the Kubernetes API. However, their permissions are restricted to managing only their specific namespace. You only pay for resources consumed by the running [pods](https://kubernetes.io/docs/concepts/workloads/pods/pod/) and persistent volume claims in your namespace. If your [Kubernetes namespace](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces) remains empty, you incur no charges.

Puzl is among the pioneering cloud providers (to our knowledge) that implement this approach. With Puzl, allocating cloud computing resources becomes simpler and more flexible, allowing for minimal requests of 0.1vCPU and 128MB of RAM.

## I already use AWS / Digital Ocean / Google Cloud / another cloud provider. Why should I consider Puzl?

There are numerous reasons to consider Puzl, but here are some key advantages:

#### 1. For teams without a dedicated DevOps engineer, managing cloud infrastructure (be it instances, droplets, or virtual machines) can be tedious. As your project expands, the time and effort required to support and orchestrate your infrastructure also increase.

Kubernetes aims to streamline the deployment and scaling of applications. This makes it a favorable alternative to traditional cloud instances. If you're new to Kubernetes or have a limited number of applications to orchestrate, Puzl is an ideal platform to learn. You don't need to deploy an entire Kubernetes cluster. At Puzl, you're billed only for the computing resources utilized by your active applications. As your application grows, adjusting its resource requests or scaling it using multiple replicas becomes a breeze, even during runtime.

#### 2. If you're using a managed Kubernetes solution from a renowned cloud provider, ensuring that your Kubernetes cluster is correctly configured with the right security policies is vital.

Overlooking certain network or pod security policies can pose significant risks, given the multitude of attack vectors targeting containerized applications. Puzl offers Kubernetes access without any complex configurations. The Kubernetes cluster is pre-configured, with established pod security and network policies. Essentially, Puzl is a plug-and-play Kubernetes solution.

#### 3. Even after correctly setting up your Kubernetes cluster in a cloud environment, it's crucial to monitor your cloud instances to ensure effective scaling. This entails not only determining when to operate or terminate instances based on your application's load but also selecting the appropriate CPU and RAM allocations. Typically, cloud providers don't offer instances with customizable resources.

Puzl eliminates the complexities of resource utilization. You no longer need to juggle the orchestration of cloud instances. Directly run pods with any resource requests. Furthermore, for applications that operate on-demand and are mostly idle, Puzl enables the creation of burstable pods. These pods can request minimal resources but have considerably higher limits. If your application occasionally uses more resources, you're billed only for the requested amount and any temporary overhead.

## How can I get started?

Simply join Puzl, and your cloud Kubernetes namespace will be operational in seconds, no special requests to the support team required. By adding a minimum balance of 10 USD, you'll instantly gain access to ample vCPU, RAM, and GPUs.

What puzl.cloud is and why you should try it, even if you already use any other Kubernetes provider

Recent articles

Cloud Services

Compute Resources
TCP/UDP Balancer
NVMe^®-based Data Storage
Shared File System Data Storage
Cloud Marketplace
Pod Configurator
Resources

Recent articles

Cloud Services

Compute ResourcesTCP/UDP BalancerNVMe®-based Data StorageShared File System Data StorageCloud MarketplacePod ConfiguratorResources

Compute Resources
TCP/UDP Balancer
NVMe^®-based Data Storage
Shared File System Data Storage
Cloud Marketplace
Pod Configurator
Resources