Forem: Ramiro Berrelleza

Chaos Engineering with Litmus and Okteto Cloud

Ramiro Berrelleza — Fri, 21 Aug 2020 17:12:57 +0000

Cloud Native applications are, by definition, highly distributed, elastic, resistant to failure and loosely coupled. That's easy to say, and even diagram. But how do we validate that our applications will perform as expected under different failure conditions?

Enter Chaos engineering. Chaos engineering is the discipline of experimenting on a software system in production in order to build confidence in the system's capability to withstand turbulent and unexpected conditions. Chaos Engineering is a great tool to help us find weaknesses and misconfiguration in our services. It is particularly important for Cloud Native applications, which, due to their distributed and elastic nature, need to be resilient by default.

Litmus is a CNCF sandbox project for practicing Chaos Engineering in Cloud Native environments. Litmus provides a chaos-operator, a large set of chaos experiments in its hub, detailed documentation, quick Demo, and a friendly community. In this blog we'll show you how you can use Litmus and Okteto together to start Chaos testing your applications in a few seconds.

Chaos Testing with Litmus

When chaos testing an application with LitmusChaos, there are four components that you'll need to keep in mind.

Chaos Operator

This is the core part of LitmusChaos. The operator is in charge of executing the experiments, and reporting the results once the experiment is finished.

You can install it directly from the command line, the official helm chart, or from the Okteto Cloud catalog.

Chaos Experiment

This is the chaos action that will performed on your application. This goes from Kubernetes specific like deleting a pod, or hogging the network, to application specific actions like randomly deleting an OpenEBS drive.

The LitmusChaos community maintains an online hub of chaos experiments.

Chaos Engine

The Chaos Engine is the link between the chaos experiment and the application under test. This is where you specify any parameters of your experiment such as its duration, enable/disable policies (e.g enable/disable monitoring) as well as information on how to find the targets of the experiment (typically, this is the application under test).

Application Under Test

This is the application that will be the "target" of the chaos experiment. Currently, LitmusChaos supports Deployments, StatefulSets and DaemonSets. Under the default configuration, you need to add the litmuschaos.io/chaos: "true" tag to the resource for the Chaos Operator to be able to find them, and to prevent other applications from being affected.

Prerequistes

To chaos-test your application you'll need to install:

The okteto CLI.
A free Okteto Cloud account.
kubectl configured to talk to Okteto Cloud.
Your favorite IDE or text editor.

Deploy your Chaos-ready Development Environment

You can always manually install every component by hand. But instead, I'm taking advantage of Okteto's pre-configured development environments. Just click on the Develop on Okteto button below and deploy your chaos-ready development environment:

This will automatically deploy the following resources on your Okteto Cloud account:

The Litmus Chaos operator, from the Okteto catalog
The pod-delete chaos experiment
The application under test

Chaos Test the Application

Now that we have our development environment, let's chaos test the application. For this example, we are using the traditional Hello World application, deployed with two replicas. Click on the link and call it a few times to verify that it works fine.

With the application running, we are ready to start the chaos experiment. In Litmus-speak, this means creating the ChaosEngine resource. Create a file engine.yaml, open it in your favorite IDE, and paste the content below:

apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata:
  name: pod-killer-chaos
spec:
  annotationCheck: 'true'
  engineState: 'active'
  appinfo:
    applabel: 'app=hello-world'
    appkind: 'deployment'
  chaosServiceAccount: default
  monitoring: false
  jobCleanUpPolicy: 'delete'
  experiments:
    - name: pod-delete
      spec:
        components:
          env:
            - name: KILL_COUNT
              value: '1'
            - name: TOTAL_CHAOS_DURATION
              value: '60s'
            - name: CHAOS_INTERVAL
              value: '15s'

The ChaosEngine resource has three main sections:

appinfo: This tells the Litmus operator which application to target. You have to specify a label selector and the type of resource.
experiments: A list of experiments to run. In this case, we are running the Pod Delete experiment.
experiments.spec.components: The experiment-specific value overrides. In this case, we are telling the experiment to kill 1 pod over 60 seconds. The available values come from the ChaosExperiment resource.

Start the chaos experiment by creating the ChaosEngine resource with kubectl:

$ kubectl apply -f engine.yaml

chaosengine.litmuschaos.io/pod-killer-chaos created

Witness the Chaos

The experiment will kill one of our application's pods. If you run the command below once the experiment has started, you'll see how a random pod is killed and then automatically recreated:

$ kubectl get pod -l=app=hello-world

NAME                                 READY   STATUS              RESTARTS   AGE
hello-world-75947547d4-2fcbc         1/1     Running             0          57m
hello-world-75947547d4-c6wsv         0/1     ContainerCreating   0          10s

While the experiment is running, keep refreshing the browser. Notice how the calls will display different pod names, but they were never interrupted? That's because our application is resilient to pod destruction 💪🏻!

When an experiment is created, a ChaosResult resource will created to hold the result of the experiment. The status.verdict key is set to Awaited while the experiment is in progress. Once it finishes, it will change to either Pass or Fail.

$ kubectl describe chaosresult pod-killer-chaos-pod-delete

Name:         pod-killer-chaos-pod-delete
Namespace:    rberrelleza
Labels:       name=pod-killer-chaos-pod-delete
Annotations:  <none>
API Version:  litmuschaos.io/v1alpha1
Kind:         ChaosResult
Metadata:
  Creation Timestamp:  2020-08-05T21:14:05Z
  Generation:          5
  Resource Version:    165298631
  Self Link:           /apis/litmuschaos.io/v1alpha1/namespaces/rberrelleza/chaosresults/pod-killer-chaos-pod-delete
  UID:                 a7f50d28-1f14-4a03-9013-94e72d69eb72
Spec:
  Engine:      pod-killer-chaos
  Experiment:  pod-delete
Status:
  Experimentstatus:
    Fail Step:  N/A
    Phase:      Running
    Verdict:    Awaited
Events:
  Type    Reason   Age   From                     Message
  ----    ------   ----  ----                     -------
  Normal  Summary  45m   experiment-l0k004-5x2fj  pod-delete experiment has been Passed

Extra Chaos

In a future post I'll show how you can take your chaos testing to the next level and write your own application-specific experiments. Can't wait? Karthik from MayaData wrote a pretty cool getting started guide. And it happens to use the okteto CLI as part of the dev flow. How cool is that?

Litmus has a monthly community call where the community gets together and talks about their cool use cases and needs. The team was nice enough to invite me to this month's call to demo the workflow I showed you on this post. It's a great place to talk and learn from other practitioners.

Conclusion

In this post, we showed how you can deploy a replicable development environment that includes an application, the LitmusChaos operator, and your chaos experiment, all in one click. Then, we ran a chaos experiment, validating that our application is resilient to a pod failure.

This is a great example of how you can use Okteto to accelerate your entire team. One person configures the app with the chaos tools, and everyone else can create their own namespace on demand, deploy a pre-configured, chaos-ready development environment, and start running experiments without having to think twice about installation scripts or infrastructure configuration.

Let's keep the conversation going! Join the Okteto and Litmus communities to talk more about Cloud Native development and Chaos Engineering.

Thanks to Karthik Satchitanand and Prithvi Raj for reading drafts of this.

Remote Development Environments with PyCharm, Okteto and Kubernetes

Ramiro Berrelleza — Tue, 12 May 2020 17:44:18 +0000

In the past, we've talked about how to develop remotely with VS Code. Today, I'm going show you how can you use okteto to define and deploy a fully configured remote development environment for your python application, how to integrate it with Jetbrains' PyCharm and how to use it to build a Cloud Native application.

The Okteto Developer platform allows you to spin up an entire development environment in Kubernetes with one click. This can be as simple as a single container or as complex as a microservice-based Cloud Native Application. You deploy your application with one click, select the component you're going to develop on, and you're ready to go in seconds.

Install Okteto

The Okteto CLI is an open source single-binary application that allows you to deploy development environments (among other things) in any Kubernetes cluster. It works with Linux, MacOS and Windows. We'll be using it to create and launch our development environment. Follow the steps below to install it:

MacOS / Linux

$ curl https://get.okteto.com -sSfL | sh

Windows

Download https://downloads.okteto.com/cli/okteto.exe and add it to your `$PATH`.

Configure your Kubernetes Access

Okteto is compatible with any Kubernetes cluster, local or remote. To keep this example simple, we are going to be using Okteto Cloud to deploy the development environment. If you prefer to use your own Kubernetes cluster, you can skip this step.

Run okteto login in your local console to create a free Okteto Cloud account, login, and to download your Kubeconfig. We'll be needing it later in the post.

$ okteto login

Authentication will continue in your default browser
You can also open a browser and navigate to the following address:
...
 ✓  Logged in as rberrelleza
 ✓  Updated context 'cloud_okteto_com' in '/Users/ramiro/.kube/config'
    Run 'okteto namespace' every time you need to activate your Okteto context again

Create a New Python Project

Start by opening PyCharm and creating a new project for your application and development environment. Pick the "Pure Python" template and call it guestbook.

Define your Remote Development Environment

At a high level, a remote development environment is a Docker container that contains everything you need to build and develop your application, such as:

One or more language runtimes (e.g python, ruby, node)
SDKs for your language runtime (e.g JDK, python-dev)
Binary dependencies (e.g. openssl, git)
Tools to manage and install dependencies (e.g. pip, bundler, yarn)
Tools to run your tests and analyze your code (e.g nosetest, pylint)

Okteto looks for a special file called okteto.yml to define the development environment for an application.

Create a file named okteto.yml in the guestbook project and copy the following content:

name: guestbook
image: okteto/python:3
forward:
  - 8080:8080
remote: 2222
command:
- bash

This file is telling okteto to perform the following:

Create a development environment named hello-world
Use the Docker image okteto/python
Start a remote SSH server on port 2222 (more on this later on)
Forward port 8080 to the remote environment
Run the bash when it starts, so we get a remote terminal.

Take a look at the manifest reference to learn the different configuration settings available.

Deploy your Remote Development Environment

Let's deploy the development environment. First, open a local terminal directly in Pycharm. Then, run the okteto up command on it.

Since this is the first time you launch your development environment, you'll be asked to confirm if you want to create it. Type y and press enter to continue.

The okteto up command will perform the following tasks automatically:

Deploy the development environment as described by okteto.yml into Okteto Cloud (or your personal Kubernetes cluster).
Forward port 8080 to the remote environment.
Start an SSH server in port 2222.
Start a file synchronization service to keep your changes up-to-date between your local filesystem and your application pods.
Launch a remote shell in your remote development environment. Now you can build, test, and run your application as if you were in your local machine.

Use your Remote Environment as an Interpreter

By default, PyCharm will use your local python interpreter for your project. Instead of that, we're going to configure it to directly use our remote development environment as the target. This way, we can guarantee that we always have the right setup, independent of what happens in our local machine. To do this, we are going to take advantage of PyCharm's remote interpreters and Okteto's remote SSH server.

To add a remote interpreter, right click on the status bar in the bottom right of the screen, and click on the Add Interpreter... option in the menu.

Then, select the SSH Interpreter option on the left, and Existing server configuration on the right.

Click on the button with the three dots in the right to launch the SSH Configuration dialog, and add a new configuration with the same values as show below, replacing /Users/ramiro with the path to your $HOME directory.

Press the Test Connection button to validate that everything is configured correctly.

When you run okteto up the first time, Okteto will create a SSH key pair for you and save it at $HOME/.okteto/id_rsa_okteto and $HOME/.okteto/id_rsa_okteto.pub. The SSH server launched in your development environment will be automatically configured to use these keys for authentication.

Once the SSH configuration is completed, click on the Next button, to get the to final configuration screen (yay!).

Update the path to the interpreter to match the one in your remote development environment (/usr/local/bin/python), set the folder mapping to /okteto and disable file uploading, since Okteto will automatically take care of this for you.

Click on the Finish button to save your configuration.

The interpreter configuration is saved in the .idea folder. You can include this configuration in your repository so the rest of your team can benefit from it.

From now on, your project will directly use the interpreter in your remote development environment, instead of the local one. Why don't you open PyCharm's python console and try it out?

Develop your Application in your Remote Development Environment

Now that we have our development environment up and running, it's time to build our application. For the purpose of this post, we are going to build a an application that lets users post messages to a public message.

The application will include:

A flask web server that handles the display and updates to the guestbook.
A MongoDB instance to store the messages.

Deploy your MongoDB Instance

One of the big advantages of using remote development environments is that we don't have to run anything locally. Since the development environment is running in Kubernetes, it has access to anything available there, such as secrets, other services, databases, etc.

For MongoDB, you can take advantage of Okteto Cloud's Application Catalog and deploy it with one click.

To do this, open your browser, go to Okteto Cloud, click on the Deploy button, select MongoDB from the list of applications, and click on the Deploy button.

Wait for a few seconds for your instance to finish deploying. You'll be able to see the status directly in Okteto Cloud's dashboard.

If you deployed your development environment in your own cluster, you can deploy it using the official Helm Chart.

Developing Directly on Kubernetes

Now that we have our development environment and our MongoDB instance, let's build our application.

First, create a python file called app.py in your project. This is the file that will contain our server's code, so let's start with the basics. Copy the code below in app.py:

from flask import Flask
from flask_pymongo import PyMongo


app = Flask(__name__)
app.config["MONGO_URI"] = "mongodb://okteto:okteto@mongodb:27017/okteto"
mongo = PyMongo(app)


if __name__ == '__main__':
    app.run(host='0.0.0.0', port=8080)

The code above will perform the following:

Import flask and flask_pymongo.
Configure the mongo connection string and data access object.
Start the webserver.

Note that we are using mongodb:27107 as the name and port of the MongoDB instance, instead of the typical localhost. This is because our development environment is running in Kubernetes, just as MongoDB, so we can access it using its DNS name. Just like we would do in production 💫.

As soon as you save the file, errors will appear on the first two lines. This is because our development environment doesn't have them installed yet. To install them, go to the console (the one with the okteto > prompt) and pip install the requirements, just like you would do locally:

rberrelleza:guestbook okteto> pip install flask flask_pymongo

...
Installing collected packages: MarkupSafe, Jinja2, itsdangerous, click, Werkzeug, flask, PyMongo, flask-pymongo
Successfully installed Jinja2-2.11.2 MarkupSafe-1.1.1 PyMongo-3.10.1 Werkzeug-1.0.1 click-7.1.2 flask-1.1.2 flask-pymongo-2.3.0 itsdangerous-1.1.0

When installing dependencies, is a good practice to add them to your requirements.txt file, so it reflects all your runtime dependencies. Run the pip freeze command in the same console:

rberrelleza:guestbook okteto> pip freeze > requirements.txt

If you wait a couple of seconds, you'll see that the requirements.txt file appears in your project automatically. This is the magic of okteto's file synchronization. Any file change in the remote development environment or locally will be automatically synchronized in the other side.

Run python app.py in the console to start the server:

rberrelleza:guestbook okteto> python app.py

 * Serving Flask app "app" (lazy loading)
 * Environment: production
   WARNING: This is a development server. Do not use it in a production deployment.
   Use a production WSGI server instead.
 * Debug mode: on
 * Running on http://0.0.0.0:8080/ (Press CTRL+C to quit)
 * Restarting with stat
 * Debugger is active!
 * Debugger PIN: 160-502-646

Your application is up and running, directly in your remote development environment. To access it, open your browser and go to http://localhost:8080. (this is why we included a forwarding rule for port 8080 in the okteto.yml manifest).

What's cool is that your application is also running on debug mode. This means that flask will automatically reload your application every time the code changes. Let's try that by finishing our application's code.

Update app.py as follows:

from flask import Flask, jsonify, request
from flask_pymongo import PyMongo

app = Flask(__name__)
app.config["MONGO_URI"] = "mongodb://okteto:okteto@mongodb:27017/okteto"
mongo = PyMongo(app)


@app.route("/", methods=["GET"])
def get_messages():
    messages = []
    for m in mongo.db.messages.find():
        messages.append({"message": m["message"], "user": m["user"]})
    return jsonify(messages=messages)


@app.route("/", methods=["POST"])
def post_message():
    content = request.json
    mongo.db.messages.insert_one({"message": content["message"], "user": content["user"]})
    return '', 204


if __name__ == '__main__':
    app.run(host='0.0.0.0', port=8080, debug=True)

With this change, the application will:

Accept a POST request on /. It will read the message and user from the request's content and insert them into the MongoDB database.
Accept a GET request on /. It will get all the available messages from MongoDB, and return them as a json array.

As soon as you save the files, okteto will detect the changes and synchronize them to your remote development environment. Then, flask will automatically reload them.

Try the application by calling the new endpoints. Open a second console in PyCharm, and post a few messages:

➜  guestbook $ curl -XPOST -H "content-type: application/json"  http://localhost:8080 -d '{"message": "hello", "user":"ramiro"}'
➜  guestbook $ curl -XPOST -H "content-type: application/json"  http://localhost:8080 -d '{"message": "how are you?", "user":"cindy"}'
➜  guestbook $ curl -XPOST -H "content-type: application/json"  http://localhost:8080 -d '{"message": "developing directly in my cluster!", "user":"ramiro"}'

And then get them:

➜  guestbook $ curl http://localhost:8080

{
  "messages": [
    {
      "message": "hello", 
      "user": "ramiro"
    }, 
    {
      "message": "how are you?", 
      "user": "cindy"
    }, 
    {
      "message": "developing directly in my cluster!", 
      "user": "ramiro"
    }
  ]
}

At this point, our application is feature complete, and we already tested it end to end in a fully integrated remote development environment. All that's left is to package it, send a PR, and ship it!

Conclusions

In this post we learned about the concept of remote development environments, why they are important, and how you can use Okteto and PyCharm to use them to build a Cloud Native application faster than ever.

But this post only covers the surface. Using remote development environments gives you a lot of extra benefits such as:

Eliminates the need for a local configuration.
Makes it simple to share the configuration with the rest of your team.
You don't need to run Docker or Kubernetes locally.
You don't depend on your workstation's state.
You can easily share your development environment with your team.
It gives you the fastest feedback loop.
You use your favorite IDEs, debuggers, etc...
You can take advantage of incremental builds and hot reloaders.
You are developing on an environment as similar as possible to production.
You don't depend on CI/CD for validating all your changes.

If this problem sounds familiar to you, you should check out what we have built at Okteto. Take a look at our getting started guide and start developing at the speed of the cloud.

Our mission at Okteto is to simplify the development of Cloud Native applications. Do this resonate with you? Do you have ideas, comments or feedback? Join us at the #okteto channel in the Kubernetes community Slack and share your thoughts with the community!

Build your React + Express App in Okteto Cloud

Ramiro Berrelleza — Mon, 27 Apr 2020 21:52:12 +0000

React is a JavaScript library for building user interfaces. It was originally created by Facebook, and over the years it has become one of the most broadly used frontend libraries. React is particularly powerful when building single-page or mobile apps.

You can build your React frontend locally. The local development experience is one of the best there is. But is very likely that, in production, your React frontend is going to to work along with other services, like a backend, or a database. What are you going to do then? Typically you'd end up mocking the backend, or calling a staging version, rendering your local development environments very complex...

In this post I'll show how you can take advantage of the different features of Okteto Cloud to make it easier than ever to build a React application. You can still benefit from React's local development experience, but you'll also have access to a fully integrated, production-like development environment, backend included. Hello okteto up, goodbye production-only bugs 👋🏼!

If you feel like skipping all the instructions, the final version of the application we are building on this post is available here.

Initial Setup

First, install the Okteto CLI. We'll be using it to create out development environment and to build and deploy our application.

MacOS / Linux

$ curl https://get.okteto.com -sSfL | sh

Windows
Download https://downloads.okteto.com/cli/okteto.exe and add it to your $PATH.

Then, create a folder for our code:

$ mkdir my-app

Launch your Development Environment

One of the big advantages of using the Okteto CLI is that it gives us the ability to define and launch development environments directly in Okteto Cloud. This way, we can have all our tools and dependencies pre-installed and available for us with one command, instead of having to mess with local configuration and conflicting setups.

Initialize your development environment by running the okteto init command. Since we are building a React app, we'll pick the javascript template:

$ cd my-app
$ okteto init

Recommended image for development with javascript: okteto/node:10
Which docker image do you want to use for your development environment? [okteto/node:10]:

 ✓  Okteto manifest (okteto.yml) created

This command will create two files in your folder, okteto.yml and .stignore. okteto.yml is what tells the Okteto CLI how your development environment looks like. In this case, it's telling it that you want to use okteto/node:10 as the image, that your workdir is /usr/src/app, and that the starting command will be bash. .stignore tells the Okteto CLI which files not to synchronize to your development environment (more on this later).

Now that we have our manifest, let's launch our development environment. First, let's login to Okteto Cloud by running the okteto login command. The command will open a browser so you can authenticate with github, and it will download your Okteto Cloud credentials and certificates. If this is the first time you use Okteto Cloud, it will also create a free account for you.

$ okteto login

Authentication will continue in your default browser
You can also open a browser and navigate to the following address:
...
...
 ✓  Logged in as rberrelleza
 ✓  Updated context 'cloud_okteto_com' in '/Users/ramiro/.kube/config'
    Run 'okteto namespace' every time you need to activate your Okteto context again.

Now that we are logged in, run the okteto up command to launch your development environment. Since this is the first time we launch it, we'll use the --deploy argument.

$ okteto up --deploy

 ✓  Development environment activated
 ✓  Files synchronized
    Namespace: rberrelleza
    Name:      my-app

Welcome to your development environment. Happy coding!
okteto>

With this, your development environment is up and running in Okteto Cloud, and you have a remote terminal to access it from (remember the bash command in okteto.yml?). But that's not all. okteto up also keeps your local folder and your remote development environment synchronized. Any file you edit, locally or remote, will be instantly synchronized in the other side (unless it's listed on .stignore).

Create the Initial App

To create the initial skeleton of the application, we're going to be using create-react-app. Run the following command on your remote development environment to build yours:

okteto> npx create-react-app client

npx: installed 99 in 16.715s

Creating a new React app in /usr/src/app/client.

Installing packages. This might take a couple of minutes.
Installing react, react-dom, and react-scripts with cra-template...
...
...
...
We suggest that you begin by typing:

  cd client
  yarn start

Happy hacking!

After a minute or two, the command will finish installing all the required files and dependencies. If you go ahead and open your local IDE you'll see that the files are already there, courtesy of okteto's file synchronization capabilities.

Follow the instructions in the UI (with a small addition) and start your React application:

export PORT=8080
cd client
yarn start

When you launch your development environment in Okteto Cloud, you automatically get a public HTTPS endpoint for it, valid certificate included. All you need to do is make sure that your process starts in port 8080 (that's why I added the export in the commands above). This way you can start accessing your application the same way your users are going to, from the very beginning. Get the URL of the endpoint by going to Okteto Cloud:

Click on the URL to see your application live in Okteto Cloud!

Develop your Application

Now that we have our initial application running, it's time to hack on it a little bit. How about we replace the React logo for Okteto's?

Load the my-app folder in your favorite IDE, and open client/src/App.js. This is the file that has the main logic of the application. Modify it so that it uses Okteto's logo instead of React's:

import React from 'react';
import './App.css';

function App() {
  return (
    <div className="App">
      <header className="App-header">
        <img src="https://okteto.com/icons/icon-384x384.png" className="App-logo" alt="logo" />
        <p>
          Edit <code>src/App.js</code> and save to reload.
        </p>
        <a
          className="App-link"
          href="https://reactjs.org"
          target="_blank"
          rel="noopener noreferrer"
        >
          Learn React
        </a>
      </header>
    </div>
  );
}

export default App;

Save the file and go to your browser. Wait for a second, and see how it automatically changes into the Okteto logo. This is the same experience you get when developing locally. But it's happening directly in your remote development environment 🧙‍♂️!

How did that happen?

When you saved the file, it automatically triggered the following events:

Okteto detected the local change, and synchronized it to your remote development environment.
The react dev server detected the change, and automatically regenerated the files.
React use their dev websocket to automatically reload the content on your browser.

Pretty cool no?

How About an API?

Now that we have our frontend running, how about giving it an API? For this example, let's create a simple API that returns the URL of the logo, instead of having it hardcoded in the URL.

We'll do our API in NodeJS, to keep things in the Javascript family. Go back to your IDE, create server.js and paste the following code on it:

const express = require('express');
const bodyParser = require('body-parser')

const app = express();
const port = process.env.PORT || 3000;

app.use(bodyParser.json());
app.use(bodyParser.urlencoded({ extended: true }));

app.get('/api', (req, res) => {
  res.json({logo: 'https://okteto.com/icons/icon-384x384.png'});
});

app.listen(port, "0.0.0.0", () => console.log(`Listening on port ${port}`));

Then, create package.json, and paste the content below.

{
  "name": "react-express",
  "main": "server.js",
  "scripts": {
    "server": "nodemon server.js"
  },
  "devDependencies": {
    "concurrently": "^5.1.0"
  },
  "dependencies": {
    "body-parser": "^1.19.0",
    "express": "^4.17.1",
    "nodemon": "^2.0.3"
  }
}

Go back to your remote terminal and stop React's web server (ctrl+c should do it). Then, go back to the workdir of your remote environment (/usr/src/app) and install the required dependencies by running yarn install:

okteto> yarn install

yarn install v1.22.4
...
...
...
success Saved lockfile.
Done in 54.50s.

Start your API by running yarn start:

okteto> yarn start

yarn run v1.22.4
warning package.json: No license field
$ node server.js
Listening on port 8080

You can validate that your API is doing the right thing by going back to the browser, add /api to the URL and hit enter. This time, you'll get the output of the API instead of your React app since that's the process that we are currently running.

To run it all together, we are going to use React's API proxy feature. This allows to both serve our static assets as well as API calls from the same server. To enable it, add the proxy key to client/package.json:

...
"proxy": "http://localhost:3000"
...

We are also going to add the following scripts to package.json to be able to start both the react dev server and server.js at the same time:

  ...
  "scripts": {
    "server": "nodemon server.js",
    "client": "yarn --cwd client start",
    "dev": "concurrently --kill-others-on-fail \"PORT=3000 yarn server\" \"DANGEROUSLY_DISABLE_HOST_CHECK=true yarn client\""
  },
  ...

Head back to your remote terminal, stop server.js and run yarn dev to start both servers this time:

okteto> yarn dev

yarn run v1.22.4
...
...

Now that be have both our React app and our API running, let's put them to work together. For this, we are going to use React's componentDidMount() hook to call the API right before the browser displays. To do this, update client/src/App.js as follows:

import React, {Component} from 'react';
import './App.css';

class App extends Component {
  state = {logo: ''};  

  componentDidMount(){
    fetch('/api')
    .then(r => r.json())
    .then(b => this.setState({logo: b.logo}))
  }

  render(){
    return(
    <div className="App">
      <header className="App-header">
      <img src={this.state.logo} className="App-logo" alt="logo" />
        <p>
          Edit <code>src/App.js</code> and save to reload.
        </p>
        <a
          className="App-link"
          href="https://reactjs.org"
          target="_blank"
          rel="noopener noreferrer"
        >
          Learn React
        </a>
      </header>
    </div>);
  }
}

export default App;

Go back to your browser and reload the page, to see everything working together. If you open your developer tools to inspect the requests, you will be able to see the call to our new API.

Ship it!

Now that our code is ready, it's time to ship it. For this, we are going to take advantage of two of Okteto Cloud's features: Okteto Build Service and the Okteto Registry.

First, let's make a final change to our application to enable production mode. Open server.js and make the following changes:

const express = require('express');
const bodyParser = require('body-parser')
const path = require('path')

const app = express();
const port = process.env.PORT || 3000;

app.use(bodyParser.json());
app.use(bodyParser.urlencoded({ extended: true }));

app.get('/api', (req, res) => {
  res.json({logo: 'https://okteto.com/icons/icon-384x384.png'});
});

if (process.env.NODE_ENV === 'production') {
  // Serve any static files
  app.use(express.static(path.join(__dirname, 'client/build')));

  // Handle React routing, return all requests to React app
  app.get('*', function(req, res) {
    res.sendFile(path.join(__dirname, 'client/build', 'index.html'));
  });
}

app.listen(port, "0.0.0.0", () => console.log(`Listening on port ${port}`));

This will allow our Node API to serve React's static files while in production mode.

Finally, create the following Dockerfile to tell Okteto how to build our application:

FROM okteto/node:10 as build

WORKDIR /usr/src/app

COPY package.json yarn.lock ./
COPY client/package.json client/yarn.lock client/
RUN yarn install
COPY . . 
RUN yarn --cwd client build

ENV PORT 8080
ENV NODE_ENV production
CMD ["node", "server.js"]

With this, we are ready to deploy the production version of our application in Okteto Cloud. Head back to your remote terminal, stop the servers by pressing ctrl+c and exit your development environment. Then, simply run okteto push to push your changes to production.

$ okteto push --deploy

 i  Development environment deactivated
 i  Running your build in Okteto Cloud...
 ...
 ...
 ------
 > importing cache manifest from registry.cloud.okteto.net/rberrelleza/my-app:okteto:
------
 ✓  Source code pushed to the development environment 'my-app'

The okteto push command automatically does everything you need to fully deploy your application in Okteto Cloud. It will: push your code changes to the Okteto Build service, build a new container remotely, tag it, push it to the Okteto Registry and automatically deploy your application. All of this (and more) in a single command!

Once the command is finished, go back to your browser and go to Okteto Cloud. You'll notice that your application no longer has an Okteto-green icon. That's because this is the production version of your application, not just your development environment!

Wrapping up

In this post we showed you how to build a React + Express app with Okteto Cloud. We talked about the benefits of developing on a fully integrated development environment when compared with just building things locally. Then we talked about how to use Okteto CLI to initialize and deploy your remote development environment. Finally, we walked through how to use the Okteto CLI and the Okteto Build and Registry Services to build, preview and ship your application.

Okteto Cloud is free for all developers. Get your own account at https://cloud.okteto.com and start building your applications today.

How to Develop and Debug ASP.NET Core Applications in Kubernetes

Ramiro Berrelleza — Mon, 02 Mar 2020 22:41:55 +0000

Kubernetes is an open-source project for automating deployment, scaling, and management of containers. It has rapidly become the standard to run production workloads and the community around it is just great!

And if you are a Windows .NET developer, then you are well aware that there are major challenges around developing applications that are meant to run in Linux containers in Windows. You can cross compile, you can dual boot, you can use WSL, etc. But those experiences are far from frictionless.

Okteto was created to solve this problem. On this blog post, we will show you how Okteto improves the developer experience in Kubernetes for ASP.NET Core developers. You will be able to take full advantage of using an instant development environment, dependency caching, hot-reloading and VS Code's remote debugging features while developing your application directly in Kubernetes.

Step 1: Deploy the ASP.NET Core Sample App

Get a local version of the ASP.NET Sample App by executing the following commands in your local terminal:

$ git clone https://github.com/okteto/aspnetcore-getting-started
$ cd aspnetcore-getting-started

The k8s.yml file contains the raw Kubernetes manifests to deploy the ASP.NET Core Sample App. Run the application by executing the command below:

$ kubectl apply -f k8s.yml

deployment.apps "hello-world" created
service "hello-world" created

This is cool! You typed one command and your application just runs 😎.

You can deploy to your own Kubernetes cluster or give Okteto Cloud a try. Okteto Cloud is a development platform for Kubernetes applications. Free developer accounts come with three Kubernetes namespaces with 8GB of RAM, 4 CPUs, and 50GB Disk space each.

Step 2: Install the Okteto CLI

The Okteto CLI is an open-source project that lets you develop your applications directly in Kubernetes while taking advantage of well-known local tooling. We will use it to speed up our development cycle instead of using the typical development workflow based on building docker images and redeploying containers.

Install the Okteto CLI:

MacOS / Linux

$ curl https://get.okteto.com -sSfL | sh

Windows

Download https://downloads.okteto.com/cli/okteto.exe and add it to your $PATH.

Step 3: Start your development environment in Kubernetes

With the ASP.NET Core sample application deployed, run the following command in your local terminal:

$ okteto up

 ✓  Development environment activated
 ✓  Files synchronized
    Namespace: rberrelleza
    Name:      hello-world
    Forward:   5000 -> 5000
               2222 -> 22

okteto>

The okteto up command starts a Kubernetes development environment, which means:

The ASP.NET Core Sample App container is updated with the Docker image okteto/dotnetcore:3. This image is based of mcr.microsoft.com/dotnet/core/sdk:3, and is preconfigured with all the required dev tools to build, test, debug and run a dotnetcore-based application.
A file synchronization service is created to keep your changes up-to-date between your local filesystem and your application pods.
Container port 5000 is forwarded to localhost.
Start a terminal into the remote container. Build, test and run your application as if you were in your local machine and get your application logs immediately in your terminal.

All of this (and more) can be customized via the okteto.yml manifest file.

To start the application, execute in the Okteto terminal:

 okteto> dotnet watch run

watch : Polling file watcher is enabled
watch : Started
info: Microsoft.Hosting.Lifetime[0]
      Now listening on: http://localhost:5000
info: Microsoft.Hosting.Lifetime[0]
      Application started. Press Ctrl+C to shut down.
info: Microsoft.Hosting.Lifetime[0]
      Hosting environment: Development
info: Microsoft.Hosting.Lifetime[0]
      Content root path: /okteto

Test your application by running the command below in a local terminal:

$ curl localhost:5000

Hello world!

Step 4: Develop directly in Kubernetes

Open Controllers/HelloWorldController.cs in your favorite local IDE and modify the response message on line 25 to be Hello world from the cluster!. Save your changes.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Extensions.Logging;

namespace helloworld.Controllers
{
    [ApiController]
    [Route("")]
    [Route("[controller]")]
    public class HelloWorldController : ControllerBase
    {
        private readonly ILogger<HelloWorldController> _logger;

        public HelloWorldController(ILogger<HelloWorldController> logger)
        {
            _logger = logger;
        }

        [HttpGet]
        public string Get()
        {
             return "Hello world from the cluster!";
        }
    }
}

Take a look at the Okteto terminal and notice how the changes are detected by dotnet watch run and automatically built and reloaded.

info: Microsoft.Hosting.Lifetime[0]
      Application is shutting down...
watch : Exited
watch : File changed: /okteto/Controllers/HelloWorldController.cs
watch : Started
warn: Microsoft.AspNetCore.Server.Kestrel[0]
      Overriding address(es) 'https://localhost:5001, http://localhost:5000'. Binding to endpoints defined in UseKestrel() instead.
info: Microsoft.Hosting.Lifetime[0]
      Now listening on: http://0.0.0.0:5000
info: Microsoft.Hosting.Lifetime[0]
      Application started. Press Ctrl+C to shut down.
info: Microsoft.Hosting.Lifetime[0]
      Hosting environment: Development
info: Microsoft.Hosting.Lifetime[0]
      Content root path: /okteto

Call your application to see the changes:

$ curl localhost:5000

Hello world from the cluster!

Notice how your code changes were instantly applied to Kubernetes. No commit, build or push required 😎!

Every time you make a change in a file, it will be automatically synchronized to your remote development environment, and the process will be hot reloaded automatically. Can you image how much more productive this is going to make you?

Step 5: Debug directly in Kubernetes

Okteto enables you to debug your applications directly from your favorite IDE. For this post, we are going to integrate Okteto's remote mode with vsdbg (the VS dotnet debugger) and VS Code's remote debugging capabilities.

For this step, we are going to use the C# extension for VS Code. If you don't have it, you can install it here.You might need to restart your VS Code instance.

Open HelloWorldController.cs in VS Code, set a breakpoint on line 26 and press F5. VS Code will connect to your remote development environment via SSH and give you a list of processes you can attach to. Scroll through the list, and select the helloworld process, as shown below (you can also type helloworld in the search bar directly).

Once you select the process, VS Code will switch to debug view, launch the debugger and attach it to the process you just selected. You'll know it's finished when the status bar at the bottom turns orange.

Go back to the terminal and call your application again:

$ curl localhost:5000

As soon as the service receives the request the execution will halt at your breakpoint and VS Code will jump to the front of the screen. You can then inspect the request, the available variables, etc. Your code is executing in your development environment in Kubernetes, but you can debug it from your local machine without any extra services or tools. Pretty cool no? 😉

How does it works?

Your development environment is configured to automatically start an SSH server in your remote development environment, a port-forward and to add an entry to your local SSH config file when you run okteto up. This allows you to use VS Code to launch a remote debugger securely, so you can develop and debug directly in your remote development environment running in Kubernetes, while coding in your favorite OS and IDE.

All of this is described via okteto.yml and the launch.json manifests. This way, everyone collaborating in your project will get the exact same configuration by simply running okteto up 🤖.

Conclusions

In this post we talked about how you can use Okteto to develop ASP.NET Core applications directly in Kubernetes, independently of your host OS. We showed you how to launch a fully configured remote development, how to iterate in your application, and how to validate the changes you make directly in Kubernetes. Finally, we showed you how you can leverage Okteto's remote mode together with VS Code's Remote Development extension to create a fully remote development environment directly in your Kubernetes cluster, debugger included!

Okteto integrates with every stack and runs in any Kubernetes instance. Let us know what you think about it on Twitter, or in the Okteto channel in the Kubernetes slack.

How to Develop and Debug Python Applications in Kubernetes

Ramiro Berrelleza — Fri, 31 Jan 2020 07:26:28 +0000

But developing in Kubernetes presents some challenges. The typical development workflow looks like this: write code, build a Docker image, push it to the registry, redeploy, validate your changes and repeat. This workflow is slow, and as anti-python as it could be. Python is famous for it's quick Read-Eval-Print loop, after all. We don't want to give that away when bulding Cloud Native applications.

Okteto was created to solve this problem. On this blog post, we will show you how Okteto improves the developer experience in Kubernetes for Python developers. You will be able to take full advantage of using an instant development environment, dependency caching, hot-reloading and even the PyCharm debugger while developing your application directly in Kubernetes.

Step 1: Deploy the Python Sample App

Get a local version of the Python Sample App by executing the following commands:

$ git clone https://github.com/okteto/python-getting-started
$ cd python-getting-started

The k8s.yml file contains the Kubernetes manifests to deploy the Go Sample App. Run the application by executing:

$ kubectl create -f k8s.yml

deployment.apps "hello-world" created
service "hello-world" created

One command and a dev version of your application is ready to go 😎.

Step 2: Install the Okteto CLI

The Okteto CLI is an open-source project that lets you develop your applications directly in Kubernetes while taking advantage of your language's toolkig. We will use it to speed up our development cycle instead of using the typical development workflow based on building docker images and redeploying containers.

Install the Okteto CLI:

MacOS / Linux

$ curl https://get.okteto.com -sSfL | sh

Windows

Download https://downloads.okteto.com/cli/okteto.exe and add it to your `$PATH`.

Step 3: Start your development environment in Kubernetes

With the Python Sample Application deployed, run the following command:

$ okteto up

 ✓  Development environment activated
 ✓  Files synchronized
    Namespace: rberrelleza
    Name:      hello-world
    Forward:   8080 -> 8080
               5678 -> 22
    Reverse:   3500 <- 3500

Welcome to your development environment. Happy coding!
okteto>

The okteto up command starts a Kubernetes development environment, which means:

The Python Sample App container is updated with the docker image okteto/python:3. This image contains the required dev tools to build, test, debug and run the Python Sample App.
A file synchronization service is created to keep your changes up-to-date between your local filesystem and your application pods.
Container port 8080 (the application) is forward to localhost.
Container post 3500 (the debugger) is reverse forwarded to localhost.
A remote shell is started in your Kubernetes development environment. Build, test and run your application as if you were in your local machine.

All of this (and more) can be customized via the okteto.yml manifest file:

name: hello-world
image: okteto/python:3
command:
- bash
workdir: /okteto
forward:
  - 8080:8080
reverse:
  - 3500:3500

You can also use the file .stignore to skip files from file synchronization. This is useful to avoid synchronizing virtual environments or git metadata.

Working in your remote development environment is the same as working on your local machine. You first create your virtual environment using the remote shell:

okteto> python3 -m venv venv

Activate it:

okteto> source venv/bin/activate

Install the service dependencies:

(venv)okteto> pip install -r requirements.txt

Collecting Click==7.0 (from -r requirements.txt (line 1))
  Downloading https://files.pythonhosted.org/packages/fa/37/45185cb5abbc30d7257104c434fe0b07e5a195a6847506c074527aa599ec/Click-7.0-py2.py3-none-any.whl (81kB)
...

Using a virtual environment in your development environment has two great benefits: You don't need to rebuild your docker image every time you add new dependencies, and the virtual environment will be cached and restored automatically when you relaunch your development environment.

And then start the application:

(venv)okteto> python app.py

 Starting hello-world server...
 * Serving Flask app "app" (lazy loading)
 * Environment: debug
 * Debug mode: off
 * Running on http://0.0.0.0:8080/ (Press CTRL+C to quit)

Test your application by running the command below in a local shell:

$ curl localhost:8080

Hello world!

Step 4: Develop directly in Kubernetes

Open the app.py file in your favorite local IDE and modify the response message on line 7 to be Hello world from the cluster!. Save your changes.

@app.route('/')
def hello_world():
    return 'Hello World from the cluster!'
}

Okteto will synchronize your changes to your development environment in Kubernetes. Flask's auto-reloader will detect the changes automatically and restart the application with the new code.

 * Detected change in '/okteto/app.py', reloading
 * Restarting with stat
Starting hello-world server...
 * Debugger is active!
 * Debugger PIN: 281-298-026

Call your application from a local shell to validate the changes:

$ curl localhost:8080

Hello world from the cluster!

Cool! Your code changes were instantly applied to Kubernetes. No commit, build or push required 😎!

Step 5: Debug directly in Kubernetes

Okteto enables you to debug your applications directly from your favorite IDE. Let's take a look at how that works in one of python's most popular IDE's, PyCharm.

First, open the project in PyCharm, remove the comments on app.py line 20.

if __name__ == '__main__':
  print('Starting hello-world server...')
  # comment out to use Pycharm's remote debugger
  attach()

  app.run(host='0.0.0.0', port=8080)

Second, launch the Remote Debug Server by clicking on the Debug button on the top right. Ensure that the Debug Tool Window shows the Waiting for process connection.. message. This message will be shown until you launch your script on the remote machine, and this script will connect to the Debug Server.

Finally, stop and star the service again:

(venv)okteto> python app.py

Starting hello-world server...
 * Serving Flask app "app" (lazy loading)
 * Environment: development
 * Debug mode: on
 * Running on http://0.0.0.0:8080/ (Press CTRL+C to quit)
 * Restarting with stat
Starting hello-world server...
Connecting to debugger...

On your local machine, switch to the Debug Tool Window. Once the service connects it will show the connection to the pydev debugger. Press the resume button to let the execution continue.

Add a breakpoint on app.py, line 10, and then call your application from your local shell:

$ curl localhost:8080

The execution will halt at your breakpoint. You can then inspect the request, the available variables, etc. Your code is executing in your development environment in Kubernetes, but is being debugged on the local machine. Pretty cool no? 😉

How does it works?

The PyCharm project includes a debugging configuration to start the remote debug server and to listen for connections on localhost:3500. The Okteto manifest is configured to start a reverse tunnel on port 3500 when the development environment is launched.

This way, when the service it's started in your remote development environment, the connection is sent back to your local machine through the reverse tunnel, where the remote debug server receives and starts the debugging process.

This configuration allows you debug your application while fully integrated in Kubernetes. And the coolest thing is that since all of this is described in your .idea and Okteto manifests, everyone collaborating in your project will get the exact same configuration by simply running okteto up 🤖.

Conclusions

Kubernetes has the potential to be a great development platform, providing replicable, resource-efficient and production-like development environments. We have shown you how to use Okteto to create a development workflow that also lets you take advantage of features like incremental builds, hot reloaders or debuggers while developing your application directly in Kubernetes.

Accelerate your development and start developing directly in Kubernetes today. Let us know what you think about it on Twitter, or in the Okteto channel in the Kubernetes slack.

Survey: Cloud Native application development

Ramiro Berrelleza — Mon, 09 Sep 2019 20:24:46 +0000

We’d like to invite you to participate in a survey we’re conducting of Cloud Native developers, users and community members. The purpose of the survey is to learn more about how you build Cloud Native applications, what you enjoy about it and the challenges that you're facing.

Click here to participate.

Your input is important so take the survey before it closes on Friday, September 20th. It only takes 2 minutes to complete. We'll be sharing the results once the survey has closed.

An Early Look At Helm 3

Ramiro Berrelleza — Tue, 03 Sep 2019 23:06:20 +0000

The first beta of Helm 3 is now available! This is a particularly important milestone because it signals the finalization of the big helm rewrite. From now on, the Helm team's focus will be in bug fixes and stability. Which means that we can start to build charts targeting Helm 3, right?

I really wanted to try Helm 3 around, but didn't want to mess my local machine (the Helm and Helm 3 binaries are not compatible, so you need to keep separate installs, $HELM_HOMEand whatnots), so instead of testing it in my machine, I decided to launch a development environment in Okteto Cloud and test everything from there.

Launch your development environment in Okteto Cloud

If this is your first time using Okteto, start by installing the Okteto CLI. We'll need it to launch the development environment into Okteto Cloud.

We'll start by initializing our development environment, using the okteto init command to create our manifest (this tells Okteto what kind of development environment to launch). Since we are working on an empty directory, okteto will ask us to pick a runtime. Pick the first one.

$ mkdir helm3
$ cd helm3
$ okteto init

Now that we have our development environment defined, we need to configure our local environment to work with Okteto Cloud.

First, run the okteto login command to create your Okteto Cloud account and link it to your local computer (you only need to do this once per computer).

$ okteto login 
 ✓  Logged in as rberrelleza
    Run `okteto namespace` to activate your download your Kubernetes credeentials.

Second, run the okteto namespace command to download the Kubernetes credentials for Okteto Cloud, and to set it as our current context.

$ okteto namespace 
 ✓  Updated context 'cloud_okteto_com' in '/Users/ramiro/.kube/config'

Now we are ready to go! Run the okteto up command to launch our development environment directly into Okteto Cloud:

$ okteto up

Deployment okteto-helm3 doesn't exist in namespace rberrelleza. Do you want to create a new one? [y/n]: y
 ✓  Persistent volume provisioned
 ✓  Files synchronized
 ✓  Okteto Environment activated
    Namespace: rberrelleza
    Name:      okteto-helm3

Welcome to your development environment. Happy coding!
okteto>

The okteto up command launches a development environment in Okteto Cloud, keeps your code synchronized between your development environment and your local machine and automatically opens a shell into the development environment for you. From now on we'll be running all the commands directly in our remote development environment (note the okteto> bash symbol in the code samples 😎).

Install Helm 3 in the development environment

Download the v3.0.0-beta.1 release from github, and install it in /usr/bin/local.

okteto> wget https://get.helm.sh/helm-v3.0.0-beta.1-linux-amd64.tar.gz -O /tmp/helm-v3.0.0-beta.1-linux-amd64.tar.gz
okteto> tar -xvzf /tmp/helm-v3.0.0-beta.1-linux-amd64.tar.gz -C /tmp 
okteto> mv /tmp/linux-amd64/helm /usr/local/bin/helm
okteto> chmod +x /usr/local/bin/helm

Run helm version to make sure everything is OK (We are dealing with beta software, after all).

okteto> helm version
version.BuildInfo{Version:"v3.0.0-beta.1", GitCommit:"f76b5f21adb53a85de8925f4a9d4f9bd99f185b5", GitTreeState:"clean", GoVersion:"go1.12.9"}

Deploying our first chart

To keep exploring Helm 3, we are going to create a simple chart by running helm create. This command creates a chart with a deployment of an NGINX container and its corresponding service.

okteto> helm create hello-world
Creating hello-world

Deploy your chart by running the helm install command:

okteto> helm install hello-world ./hello-world
NAME: hello-world
LAST DEPLOYED: 2019-08-29 23:01:17.851466604 +0000 UTC m=+0.128796294
NAMESPACE: rberrelleza
STATUS: deployed
....

You can then run helm list to see all the installed releases:

okteto> helm list
NAME                    NAMESPACE   REVISION    UPDATED                                 STATUS      CHART
hello-world             rberrelleza 1           2019-08-29 23:06:40.982957007 +0000 UTC deployed    hello-world-0.1.0

When you launch a development environment in Okteto Cloud, a set of credentials is automatically created for you. The credentials are automatically mounted on your development environment, so you can start using tools like helm or kubectl without requiring extra configuration.

Instead of having to run a port-forward to our local machine, we will let Okteto Cloud automatically create a publicly accessible SSL endpoint for our application by annotating the service with dev.okteto.com/auto-ingress=true. The chart created by helm create doesn't support annotations, so we'll just use kubectl annotate directly:

okteto> kubectl annotate service hello-world dev.okteto.com/auto-ingress=true
service/hello-world annotated

Let's open our browser and head out to Okteto Cloud to see the application's endpoint.

Let's go ahead and cick on the URL to see our application up and running.

Helm 3.0.0-beta.1 can't install charts from a repository due to #6287. It'll be fixed in the next beta release.

Upgrading the chart

Let's change the boring "Welcome to nginx page!" with something with more flair. We'll upgrade our chart and change the container image from nginx to ramiro/hello using the helm upgrade command.

okteto> helm upgrade --set image.repository=ramiro/hello hello-world ./hello-world

Run helm list to see the state of the release. Notice how the value of revision changed from 1 to 2 to indicate that a new version was deployed.

okteto> helm list
NAME        NAMESPACE   REVISION    UPDATED                                 STATUS      CHART
hello-world rberrelleza 2           2019-08-30 00:05:57.204015932 +0000 UTC deployed    hello-world-0.1.0

Go back to your browser, reload the page, and verify that it was correctly upgraded 🐶.

Cleanup

Use the helm uninstall command to uninstall the chart and remove all the related resources.

okteto> helm uninstall hello-world
release "hello-world" uninstalled

Once you're done playing with your development environment, exit the terminal and run the okteto down command to shut it down. But don't worry, all the files you created there (like the chart) were automatically synchronized back to your local machine.

Conclusion

I'm really excited about Helm 3. The team managed to keep all the good things about it (repeatable installations, manifest-driven approach, easy to share charts, same commands) while removing the need to have a central service to keep all the state (buh bye Tiller!). Can't wait to get my hands on the final version!

Ephemeral development environments are a great way to keep different tech stacks from messing with each other, or to quickly try out beta software without "polluting" our machine. Making them super easy to use for everyone is one of our main motivations with building Okteto.

I would ❤️ to hear what you think about this feature.

How to develop a serverless app with OpenFaaS and Okteto

Ramiro Berrelleza — Tue, 13 Aug 2019 05:01:04 +0000

How to Develop a Serverless App with OpenFaaS and Okteto

Okteto + OpenFaas

OpenFaaS (Functions as a Service) is a framework for building serverless functions with Docker and Kubernetes.

OpenFaaS simplifies your application by helping you package your application logic in discrete packages that react to web events. Instead of having to deploy tens of pods to keep your application running at scale, OpenFaaS scales your functions automatically and independently based on web events and metrics.

On this blog post we'll show you how to deploy your own instance of OpenFaaS, launch your first function and how to develop it. Then we'll show you how you can use the Okteto CLI to accelerate your serverless development even more.

Deploy OpenFaaS in Okteto Cloud

If you already have your own installation of OpenFaaS, feel free to skip to the next step.

For this post, we'll deploy OpenFaaS into Okteto Cloud. Okteto Cloud is a self-service, multi-tenant Kubernetes cluster optimized for team collaboration and Cloud Native development.

Log in to Okteto Cloud and click on the Deploy button. Switch the deploy method to Deploy from Helm Chart, select OpenFaaS, pick a password, and click deploy. Your OpenFaaS instance will be up and running in a matter of seconds.

OpenFaaS includes a web gateway as part of the deployment, which can be used to see your functions, create new ones, and to invoke them. Okteto Cloud automatically created an ingress for your OpenFaaS gateway. Open Okteto Cloud in your browser and click on the gateway URL to access it.

When opening the gateway the first time you will be prompted for credentials. The user is admin and the password will be the content of the Password field you provided in the deployment dialog (it defaults to Password123!).

Install the OpenFaaS CLI

We need the OpenFaaS CLI available locally to deploy a function. If you are in Mac or Linux, run the command below to install it:

$ curl -sL cli.openfaas.com | sudo sh

On Windows download the latest faas-cli.exe from the releases page and place it somewhere in you $PATH.

Validate that it was installed correctly by opening a terminal and running:

$ faas-cli help
$ faas-cli version

To access the OpenFaaS gateway from the CLI, you need to export the $OPENFAAS_URL and $OPENFAAS_PASSWORD environment variables (you can get your gateway's URL from Okteto Cloud's) and login using the faas-cli login command:

export OPENFAAS_URL=$OPENFAAS_GATEWAY_URL
export OPENFAAS_PASSWORD="Password123!"
$ echo $OPENFAAS_PASSWORD | faas-cli login -u admin --password-stdin

Calling the OpenFaaS server to validate the credentials...
credentials saved for admin https://gateway-rberrelleza.cloud.okteto.net

Deploy your first function

Now that we have our instance of OpenFaaS, it’s time to deploy our first function.

OpenFaaS supports pretty much any programming language, but since I'm a huge golang fan, we'll use that for this post. Use the faas-cli new command to create all the necessary files.

$ faas-cli new -lang go gohash
...
  ___                   _____           ____
 / _ \ _ __   ___ _ __ |  ___|_ _  __ _/ ___|
| | | | '_ \ / _ \ '_ \| |_ / _` |/ _` \___ \
| |_| | |_) |  __/ | | |  _| (_| | (_| |___) |
 \___/| .__/ \___|_| |_|_|  \__,_|\__,_|____/
      |_|Function created in folder: gohash
Stack file written: gohash.yml
...

We now have a folder called gohash with a file called handler.go, this is the main code of our function. We also have a file called gohash.yml with the function metadata, and a folder called template with the different function templates available.

Open gohash.yml with your favorite text editor and put your Docker Hub account into the image: section. i.e. image: okteto/gohash:latest.

Then, run the faas-cli up command to build, push and deploy your function.

The faas-cli up command uses your local Docker client to build and push the images. It requires you to be logged to Docker Hub or a similar registry.

$ faas-cli up -f gohash.yml
[0] > Building gohash.
...
[0] < Building gohash done.
[0] worker done.

[0] > Pushing gohash [ramiro/gohash:latest].
...
[0] < Pushing gohash [ramiro/gohash:latest] done.
[0] worker done.

Deploying: gohash.

Deployed. 202 Accepted.
URL: https://gateway-openfaas-rberrelleza.cloud.okteto.net/function/gohash

Once your function has been deployed, we'll use the gateway's UI to invoke it. Open the gateway in your browser, click on the gohashon the left, type testas the Request body, and click the _Invoke _button.

Your first OpenFaaS function

Develop your function

Once our function is up and running, let's add a simple feature. Instead of just echoing back the input, we'll calculate the checksum of the string and return that instead.

Open gohash/handler.go with your favorite editor, and update it:

Save the file, and build , push and deploy your function with the faas-cli up command.

$ faas-cli up -f gohash.yml
...
...
Deployed. 202 Accepted.
URL: https://gateway-rberrelleza.cloud.okteto.net/function/gohash

Wait 30 seconds, go back to the gateway's UI and invoke the function again to verify your code change:

Result of the function after adding the checksum

You'll need to edit the handler.go file and run faas-cli up every time you want to deploy a new change.

Develop your function, Cloud Native style

OpenFaaS offers you a great experience when building functions (way better and AWS Lambda and GCP's Cloud Functions, in my opinion), but having to build, push and redeploy every time you want to change a line of code adds a lot of friction to my inner loop.

What if instead of building, pushing and deploying, we take advantage of Okteto and develop our function directly in the cluster, Cloud Native style?

Okteto uses a manifest to know how to build and deploy your development environment. Create an file called gohash/okteto.yml, with the following content:

name: go-dev
image: okteto/openfaas:golang
mountpath: /go/src/handler/function
command: ["bash"]
securityContext:
 fsGroup: 100
services:
 - name: gohash
 mountpath: /home/app/src
 environment:
 - fprocess=src/handler

Go to your terminal, navigate to the gohash folder and run the okteto up command to start your remote development environment:

$ cd gohash
$ okteto up

Deployment 'go-dev' doesn't exist. Do you want to create a new one? [y/n]: y
 ✓ Persistent volume provisioned
 ✓ Files synchronized
 ✓ Okteto Environment activated
 Namespace: rberrelleza
 Name: go-dev

Welcome to your development environment. Happy coding!
okteto>

Build and install the binary in your remote environment:

okteto> go install

If you want to use go build instead, call it like this: go build -o /go/src/handler/function for OpenFaaS to pick it up the changes.

Go back to the browser, and test the function again:

Result of the function running with Okteto

Now, let's implement a second feature: We'll include a timestamp in the response. Open gohash/handler.go.go with your favorite editor and update it:

Save your file, go back to your terminal, and build your function again.

okteto> go install

Go back to your browser, and test your function again:

Result of the function after adding the timestamp

Our change made it to the function! How did this happen? With Okteto your changes were automatically applied to the remote containers as soon as you saved them. This way you can execute native go builds, leveraging golang's caches and incremental builds to see your changes in seconds. No commit, build, push or redeploy required 💪!

Once you're done developing, run okteto down to return everything to the previous state.

Whoa, how does it works?

When you run okteto up, Okteto enables what we call development mode. Development Mode is what enables you to test your changes directly in the cluster, instead of having to build, push and redeploy.

After running okteto up the following events happen:

Okteto creates a persistent volume on Okteto Cloud.
A bi-directional synchronization service is started between your local machine and the persistent volume.
Okteto launches your development environment, using the image you defined in your okteto.yml, with your persistent volume mounted. The deployment will use the image defined in your manifest. In this case, we are using okteto/openfaas:golang, an image that has all the tools you need to develop golang-based functions already preinstalled.
Okteto relaunches all the deployments defined in the services section of your manifest (in this case, your function). The deployment is slightly modified to have your persistent volume mounted in mountpath, and the environment variable fprocess injected.
A shell was opened into your development environment.

Your function in Okteto's development mode

Every time you change a file (e.g when you add the timestamp code), the code is synchronized between your machine and your remote environment. And every time you compile your go binary, the updated version is available both in your development environment and in your function's deployment (since they both share the same volume).

This is the 'magic' that allows you to validate your changes directly in the cluster, no commit, build, push or redeploy required. Join us on slack to talk more about Okteto's features, architecture, and use cases!

Conclusions

We just built and deployed our first function in OpenFaaS in minutes.

OpenFaaS makes it simple to turn anything into a serverless function that runs on Linux or Windows through Kubernetes. Learn more about OpenFaaS here.

And then, we used Okteto to show you the advantages of developing directly in Kubernetes while keeping the same developer experience than working on a local machine. By developing directly in the cluster you not only gain speed, you also avoid the burden of having to keep Kubernetes and OpenFaaS running in your local machine.

Working on the Cloud is always better. You don’t work on your spreadsheets and listen to media files locally, do you? Stop dealing with local environments and become a Cloud Native Developer today!

Interested in boosting your team's Kubernetes development workflows? Contact us to start running Okteto Enterprise in your own infrastructure today.

Develop a Django + Celery app in Kubernetes

Ramiro Berrelleza — Thu, 27 Jun 2019 14:26:15 +0000

Develop a Django + Celery App in Kubernetes

Django + Celery is probably the most popular solution to develop websites that require running tasks in the background. Developing a Django + Celery app locally is complex, as you need to run different services: Django, Celery worker, Celery beat, Redis, databases… docker-compose is a very convenient tool in this case. You can spin up your local environment with docker-compose in just one single command. And thanks to the use of volume mounts, you are able to hot reload your application in seconds.

In this blog post, we want to go a step forward and explain why you should develop your Django + Celery app directly in Kubernetes. The benefits are:

Reduce integration issues by developing in a more production-like environment, consuming Kubernetes manifests, secrets, volumes or config maps from development.
Overcome local development limitations. You will be able to develop against any Kubernetes cluster, local or remote. And having a lot of microservices makes it harder and harder to run the entire development environment locally.

But it is well-known that developing in Kubernetes is tedious. Let’s explore together how to develop in Kubernetes the Cloud Native way 💥💥💥💥.

Deploy the Django + Celery Sample App

Get a local version of the Django + Celery Sample App by executing the following commands in your local terminal:

$ git clone https://github.com/okteto/math
$ cd math

The Django + Celery Sample App is a multi-service application that calculates math operations in the background. It consists of a web view, a worker, a queue, a cache, and a database.

Execute the command below to deploy the application in your Kubernetes cluster:

$ kubectl apply -f manifests
statefulset.apps "cache" created
service "cache" created
statefulset.apps "db" created
service "db" created
statefulset.apps "queue" created
service "queue" created
deployment.apps "web" created
service "web" created
deployment.apps "worker" created

Wait for a few seconds for the app to be ready. Check that all pods are ready by executing the command below:

$ kubectl get pod
NAME READY STATUS RESTARTS AGE
cache-0 1/1 Running 0 2m
db-0 1/1 Running 0 2m
queue-0 1/1 Running 0 2m
web-7bccc4bc99-2nwtc 1/1 Running 0 2m
worker-654d7b8bd5-42rq2 1/1 Running 0 2m

Efficient Kubernetes Development with Okteto

Now that we have the Django + Celery Sample App running in a Kubernetes cluster, we can use it as our development environment. When working in Kubernetes, you would have to rebuild your docker images, push them to a registry and redeploy your application every time you want to test a code change. This cycle is complex and time-consuming. It sounds like a bad idea to kill your productivity this way.

If you are familiar with docker-compose, you know how useful is to mount local folders into your containers to avoid the docker build/push/redeploy cycle. Volume mounts are a game changer for developing Docker applications and they are the missing piece to speed up your Kubernetes development cycle.

We developed Okteto to solve this problem. To give you all the good parts of using docker-compose when developing while moving your development into your Kubernetes cluster. Okteto is open source, and the code is available in github. Feel free to check it out, contribute, and star it 🤗!

To install the Okteto CLI in your computer, follow the installation instructions and check that it is properly installed by running:

$ okteto version
okteto version 1.8.18

Okteto CLI >= 1.8.18 is required to follow this tutorial.

In order to start developing the Django + Celery Sample App, execute:

$ okteto up
✓ Files synchronized
✓ Okteto Environment activated
 Namespace: pchico83
 Name: web
 Forward: 8080 -> 8080

curl: (52) Empty reply from server
Database is ready
No changes detected in app ‘myproject’
Created migrations
Operations to perform:
Apply all migrations: auth, contenttypes, myproject, sites
Running migrations:
No migrations to apply.
Migrated DB to latest version
Performing system checks…
System check identified no issues (0 silenced).
June 26, 2019–11:00:02
Django version 1.11.21, using settings ‘myproject.settings’
Starting development server at http://0.0.0.0:8080/
Quit the server with CONTROL-C.

Let’s have a look at the okteto.yml file to understand what the okteto up command does:

name: web
command: ./run_web.sh
sync:
  - .:/app
services:
  - name: worker
    command: ./run_celery.sh
    sync:
      - .:/app
forward:
  - 8080:8080

okteto up synchronizes your local source code to the containers of the deployment web and worker. Your source code is synchronized to the container path /app. Also, the port 8080 is automatically forwarded between your development container and your computer. If you want to know more about how Okteto works, follow this link.

Let’s Write some Code and Fix a Bug

Verify that the application is up and running by opening your browser and navigating to http://localhost:8080/jobs/. Go ahead and calculate the fibonacci for the number 5:

Press the POST button to submit the operation. The response payload will include the url of the job. Go to http://localhost:8080/jobs/1/ and you will notice that the result is wrong (hint: the fibonacci number of 5 is not 32). This is because our worker has a bug 🙀!

Typically, fixing this would involve you running the app locally, fixing the bug, building a new container, pushing it and redeploying your app. Instead, we’re going to do it the Cloud Native way .

Open myproject/myproject/models.py in your favorite local IDE. Take a look at the value of the task variable in line 29. It looks like someone hard-coded the name of the operation instead of reading it from the job. Let's fix it by changing it to self.type , as shown below:

task = TASK_MAPPING[‘power’]

task = TASK_MAPPING[self.type]

Save your file and go back to http://localhost:8080/jobs/. Submit a new fibonacci calculation for the same values as before. Go to http://localhost:8080/jobs/2/ and verify the result. The result looks correct this time, success!

How did this happen? With Okteto your changes were automatically applied to the remote containers as soon as you saved them. No commit, build, push or redeploy required 💪!

Okteto can be used in local Kubernetes installations, but why would you limit yourself to develop locally when you can develop at the speed of the cloud? Developing in the cloud have several advantages, among others:

The cloud offers faster hardware.
Your company might deploy a few services to make them available to every development environment, like a Kafka instance or a company Identity Service.
Consume infrastructure services like Elasticsearch or Prometheus from development to boost debugging.
Share your development environment endpoints with the rest of your team for fast validation.

Every developer should work in an isolated namespace, sharing the same Kubernetes cluster. Okteto Enterprise takes care of setting Roles, Network Policies, Pod Security Policies, Quotas, Limit Ranges and all the other tedious work needed to provide controlled access by several developers to the same Kubernetes cluster. If you want to give it a try, follow our getting started guide.

Cleanup

Cancel the okteto up command by pressing Ctrl + C and run the following commands to remove the resources created by this guide:

$ okteto down -v
✓ Okteto Environment deactivated

$ kubectl delete -f manifests
statefulset.apps "cache" deleted
service "cache" deleted
statefulset.apps "db" deleted
service "db" deleted
statefulset.apps "queue" deleted
service "queue" deleted
deployment.apps "web" deleted
service "web" deleted
deployment.apps "worker" deleted

Conclusions

We have shown the advantages of developing directly in Kubernetes while keeping the same developer experience than working on a local machine. Working on the Cloud is always better. You don’t work on your spreadsheets and listen to media files locally, do you? Stop dealing with local environments and become a Cloud Native Developer today!