For more than a year now, Jarred Sumner and his team have been working on a new open source JavaScript runtime: Bun. It's touted as more efficient and feature-rich than current solutions such as Node.js or Deno. Version 1.0.3 has just been released, and you can already use it for your projects hosted by Clever Cloud.

While we like to automate and simplify everything for our customers, we do so while leaving as much freedom as possible. Thus, hosting a Node.js application with the framework or package manager of your choice can be done without any particular constraints, and deploying a website takes only a few minutes.

We already support Deno, Meteor.js, yarn. While we haven't yet taken the decision to integrate Bun natively into our images, as we await initial feedback from our customers, it's all very straightforward.

Hello, Bun on Clever Cloud!

Want to give it a try? All you need is a Clever Cloud account, or create one from an e-mail address or GitHub account. We'll give you 20 euros worth of credits when you sign up.

• Create a Clever Cloud account (and get 20 euros in credits)

For this first example, we'll assume that you have a machine running git and a recent version of Node.js. If you haven't yet installed our open source Clever Tools command line interface (CLI), type (with administrator rights on your system or sudo if necessary) :

npm i -g clever-tools
clever login

Once logged in, you can check that everything has gone correctly with the following command:

clever profile

Let's install Bun and create our first application:

npm install -g bun
mkdir clevbun && cd clevbun
bun init -y && git init

This will create a local git repository and a whole series of files, including package.json which contains your project's configuration. But also index.ts and ts.config.json, which are specific to the TypeScript language used by Bun by default. Don't worry, it handles simple JavaScript files just as well as JSX/TSX, ECMAScript and CommonJS modules, which are imported in a unified way, low-level languages or SQLite. That's one of its strengths.

Let's check that everything worked as planned:

> bun index.ts
Hello via Bun!

An application using Bun's HTTP server

Our aim is to host a web application, so we're going to use an HTTP server. It's a good thing that Bun has its own, in addition to ensuring compatibility with Node.js functionalities and APIs. Developed using the Zig language, using the JavaScriptCore engine rather than v8, this runtime claims to be much more efficient for such uses.

Modify the contents of the index.ts file as follows:

Bun.serve({
  port: 8080,
  hostname: '0.0.0.0',
  fetch(req) {
    const url = new URL(req.url);
    if (url.pathname === "/") return new Response("Home page!");
    if (url.pathname === "/blog") return new Response("Blog!");
    return new Response("404!");
  },
  error(error) {
    return new Response(`<pre>${error}\n${error.stack}</pre>`, {
      headers: {
        "Content-Type": "text/html",
      },
    });
  },
});

This creates an HTTP server that sends a different response depending on the route (url.pathname) and a 404 error if none matches. If a problem occurs, a dedicated page will be displayed. Note that port 8080 is here specified in the code, but it could be defined with an environment variable: $PORT, $BUN_PORT or $NODE_PORT.

Clever deploy!

Now let's get down to the nitty-gritty of deploying on Clever Cloud, starting by preparing the application:

clever create -t node clevbun
clever env set CC_PRE_BUILD_HOOK "npm i -g bun"
clever env set CC_NODE_BUILD_TOOL "custom"
clever env set CC_CUSTOM_BUILD_TOOL "bun install"
clever env set CC_RUN_COMMAND "bun run index.ts"

The first command creates the application within your Clever Cloud account. Then we define environment variables for installing Bun within the image, followed by instructions for configuring dependencies and launching the project. As with Node.js, you can specify that an application is ready for production by assigning the value production to the NODE_ENV environment variable.

It is then available from our infrastructure and opened in your browser. Note that you can use this configuration to use Bun on a Node.js application already hosted by Clever Cloud by adapting CC_RUN_COMMAND to your project.

Now that our application has been created, it can be deployed. It's as simple as a git push!

git add . && git commit -m "First commit"
clever deploy && clever open

This should deploy the application on our infrastructure and open it in your browser. You can add /blog or /random at the end of the URL to check that routing works properly.

Many possibilities

You don't have to worry about configuring HTTPS access, log collection or metrics - everything is already set up, accessible through Clever Tools or the Console. You can also use the latter to activate Grafana in your account settings.

clever console

Other Clever Tools features let you assign it a domain, view its parameters and activity, modify the number and type of instances used, and stop or restart it. Take a look at our CLI help with --help or its documentation to find out more:

clever domain
clever domain add domain.tld

clever status
clever activity

clever scale --min-instances 1 --max-instances 4 --min-flavor pico --max-flavor M
clever scale --instances 1 --flavor pico

clever restart
clever stop

Of course, you can also go further with Bun and deploy applications using the Elysia web framework or static site generators such as Astro. We'll tell you all about that in future blog posts! Meanwhile, let us know what you expect from our JavaScript runtime images.

In this article, we will learn how to configure JAAS authentication in a JVM application without resorting to configuration files. This is motivated by the fact that, in a cloud setup, persisting a configuration file to an ephemeral instance/container is not a good practice.

The problem

You are writing an application that depends on a ZooKeeper cluster. The moment comes when you need to put your code into production. During the early development of your application you were running a ZooKeeper instance on your laptop. Now that you are deploying to production, you need a secure connection between your app and the production ZooKeeper cluster you just set up.

Reading the ZooKeeper documentation you learn that you can achieve that through multiple ways: X509, SASL Kerberos, SASL Digest. Since you just want to demonstrate your POC, you have no wish to take on the burden of using X509 client certificates or to deploy a Kerberos architecture. So you fallback to SASL Digest. It's simple and easy, it's a user/password pair like you are used to.

Reading some more documentation you learn that you have to put the credentials in a jaas.conf file. You then look into the internet to find a way to bypass this requirement.

Well, your search is over, your quest ends with this very article!

You just want to copy some code and don't care about the whole "let's talk about X" part? Jump to the "How to get rid of jaas.config file" section!

Some explanations first

Since Java 1.4, a security framework has been added to the JRE: the Java Authentication and Authorization Service (JAAS).

JAAS is a quite comprehensive and pluggable framework. The only downside is that it's thought as a service meant to authenticate "the user running the code". So it has a tendency to use configuration files or even system JVM configuration.

Configuration based on files containing secrets is a growing no-go in the cloud era. Since most clouds rely on disposable systems, using a JAAS file means one of the following:

1. commiting the file, with the secrets in it;
2. commiting a file and use pre-run hooks to set the right value in it;
3. running an external service that would provide this file.

Solution 1 is a strict no-go. Solution 2 is doable, but as a developer, I don't like having to resort to such practices. However, it's still better than solution 1, I'm just stating my very personal point on view! Solution 3 is a bit like solution 2. It needs some kind of pre-run hook. In addition, it needs to trust the external source.

In this article, we will see how to abstract ourselves from the file-based JAAS login configuration. I will use a ZooKeeper Java/Scala client as an example.

What's in the box JAAS file?

First, what is a JAAS file made of?

As the Oracle documentation states, it is made of entries. Each entry is composed of multiple modules. Each module provides a login/authorization mechanism with all its options. An authentication/authorization process has to satisfy all modules of the entry to succeed.

Example

We assume that the server part is already configured. Here we focus on the client part only.

Let's say we want to authenticate a Java application against a ZooKeeper cluster using the DIGEST-MD5 SASL mechanism. We write a jaas.conf file somewhere on the filesystem. Here is what the file content will look like:

Client {
   org.apache.zookeeper.server.auth.DigestLoginModule required
   username="buffysummers"
   password="vampiresbeware";
};

The entry name is Client (the default client session name for ZooKeeper). There is one module identified by the FQDN of the LoginModule class that will process the authentication/authorization. This module is required and has two parameters: username and password. No spaces around the =, the semicolon separates the modules. So only one is needed at the end of the module. One is also needed after the entry.

"Executing" this entry is quite straightforward: Java instanciates the org.apache.zookeeper.server.auth.DigestLoginModule class and calls initialize("subject", callback, sharedState, Map(username=buffysummers, password=vampirebeware)) on the instance. After that, the actual client will use the instance's methods to perform authentication/authorization.

It's the developer's responsibility to ensure the module class is present in the classpath. In the case of ZooKeeper, the library provides the org.apache.zookeeper.server.auth.DigestLoginModule class.

Oh, one last thing about the JAAS file syntax: for each module you must say if the module is required, sufficient, optional, etc. That's what the required keyword is about! That way you can require multiple authentication methods to pass or you can just ask for one of them to pass.

How does it work in the JVM?

When running your application, the client code will use the javax.security.auth.login.Configuration static class to access your configured JAAS. Actually, it will use the only JRE provided implementation com.sun.security.auth.login.ConfigFile, which parses your provided jaas.conf file.

The Configuration singleton provides one method, getAppConfigurationEntry(String entryName). In our example, by default, the ZooKeeper client calls the method with the string "Client".

In most JREs, there is no default JAAS file. That means Configuration has no entries.

How do I tell the JVM where to find jaas.conf?

According to the javadoc, there are multiple ways to do that:

• edit the java.security system file (in $JAVA_HOME);
• run your app with the java option -Djava.security.auth.login.config=path/to/jaas.conf;
• put the file in the default location: $HOME/.java.login.config.

The next section will show us how to setup your JVM using Java code, without relying on the filesystem. It will keep on using the ZooKeeper client example.

How to get rid of jaas.config file

The answer to that is quite simple: override Java's Configuration default implementation!

Disclaimer

Before we dive in the details, please note that There is only one Configuration object installed in the runtime at any given time. When we override it, we remove all previous login configurations. Most JREs do not have any default configuration, so you should be safe. However, if you deploy your application in your company's VMs or container, they may already have specific configuration. So ask around!

Implementing a new Configuration

First, we define a class that implements javax.security.auth.login.Configuration:

import javax.security.auth.login.AppConfigurationEntry;
import javax.security.auth.login.Configuration;
import java.util.HashMap;
import java.util.Map;

public class MyConfiguration extends Configuration {
   AppConfigurationEntry[] getAppConfigurationEntry(s: String) {
      Map<String,String> options = new HashMap<>();
      options.put("username", "buffysummers");
      options.put("password", "vampiresbeware");

      return {
         new AppConfigurationEntry(
               "org.apache.zookeeper.server.auth.DigestLoginModule",
               AppConfigurationEntry.LoginModuleControlFlag.REQUIRED,
               options
               )
      };
   }
}

Of course, you are highly encouraged to get the values for username and password from the environment, from a config database, or whatever you want! You might even add a constructor and feed it the credentials. You do you!

The next step is to instanciate it. You need to do it before you create a new ZooKeeper client instance:

// 1. Do that somewhere *before* creating the ZooKeeper instance.
// I would say do it close enough so other people can understand why you do it, or
// document this call because it is kind of cryptic.
Configuration.setConfiguration(new MyConfiguration());

// 2. Just create the zookeeper instance as usual!
ZooKeeper zookeeper = new ZooKeeper("localhost:2181", 3600000, watchCallback);

// 3. ?

// 4. PROFIT!

And that's it.

Alternative method

When writing this article, I read the documentation a bit more in depth and found out that I could use Java properties in the JAAS configuration file!

So instead of the code-only solution, we could actually just commit a jaas.conf file containing:

Client {
   org.apache.zookeeper.server.auth.DigestLoginModule required
   username="${app.zookeeper.username}"
   password="${app.zookeeper.password}";
};

Then run your Java application with the Java options: -Dapp.zookeeper.username=buffysummers and -Dapp.zookeeper.password=vampirebeware.

I tried it, it works!

Depending on your application, using this solution might be easier than the full-code one.

Conclusion

Now that we understand a bit more about JAAS and how to avoid using the file format, there is actually only one advice to keep in mind: DO NOT STORE CREDENTIALS IN YOUR GIT REPOSITORY! By using one of the two proposed solutions, you should be able to have the secrets provided by the environment.

Besides, both of them should work on Clever Cloud. Your environment variables are injected in your application both as environement and as Java properties! You can also define a variable named app.zookeeper.username. It will only appear as a Java property, due to limitations in environment variables names.

In ancient times, developers weren't able to be just developers. They had to be experts in computer networking and development platforms as well.

Great ideas had to sit on the sidelines and wait. You had to build out a sandbox to play in before you started coding. If you wanted to use Ruby (on or off Rails), you had to start with something like Ruby Version Manager (RVM) to set up the server space you needed. If you decided that Node.JS was a better fit for your next application, you would have to tear it all down and go get Node Version Manager (NVM) from GitHub. Obviously, people couldn't live that way for long.

The Dawn of Reason

Platform as a Service (PaaS) providers started popping up about a decade ago and civilization took off from there. Now developers worry about development and the host manages the OS, the software stack, the runtime, the servers, virtualization and storage. That problem then became that PaaS providers were too narrow in their focus.

That's when Clever Cloud Driven Development (CCDD) was born. It evolved the concept of PaaS and made it polyglot. That means that now you have the freedom to work in any of your preferred runtimes (Docker, PHP, Scala, etc.) and have access to your favorite services (MongoDB, PostgreSQL, Redis, etc.). Now, instant access to those capabilities can be deployed with a simple git push.

Tell Me How

One of the tricks that do the magic is the Clever Tools™, the official and open-source CLI. Installing it allows the rest of us to use Clever Cloud deploying without leaving the terminal. And that's pretty awesome.

…deploying without leaving the Terminal.

Here the quickstart to install and use it without leaving this page: open your term and paste this:

# Do this once, and forget about it
npm install -g clever-tools && install-clever-completion && clever login

# Go to your workDir
# For the Terminalesque ones, create your app without touching a mouse
clever create -t node "My Great Application"
clever deploy
## PROFITT
clever open
## Grep logs as in ye olden days
clever logs --before 2016-10-13 | grep "undefined is not a function"

What to Do With All the Extra Time

CCDD is not merely a convenience. It actually makes the app world a better place™. It allows developers to do a better job at continuous delivery. When you don't have to set up and maintain your local environment, your time is freed up to create the additional features that customers want or concentrate on performance tuning.

You don't need to manage your sandboxes for dev and production. CCDD can update your apps in production with no downtime and assure that they will automatically self-heal and redeploy after a crash.

For lean startups and small developer teams, CCDD means scalability from day one. You don't need to invest in more servers to handle spikes in traffic if you suddenly someone says something nice about you on Hacker News (one can only hope). CCDD scales horizontally and vertically as needed in an instant.

Every developer deserves top-of-the-line security and reactive monitoring. CCDD is built to handle the infrastructure while you handle the accolades.

Step 1. Submit an Excerpt

Step 2. Write and Publish your Tutorial

Step 3. Profit!

It has already started by trainings sessions today and tomorrow and the speakers will burst in on the scene next wednesday and thursday.

If you are looking at going to QCON London, you can save £100 using the code “ADAM100”.

See ya!

French version:

Clever Cloud à la QCON LONDON

Quentin ADAM, CEO de Clever Cloud, sera à la QCON London jeudi prochain, le 7 mars pour parler de JavaScript comme langage de traitement de données et d’intégration HTML5. Pour rappel, la QCON London 2013 est la septième édition de cet évènement annuel dédié aux développeurs, à l’architecture logicielle et au management de projet.

L’event a déjà débuté par les séances de trainings aujourd’hui et demain alors que les conférences débuteront à partir de mercredi.

Si vous souhaitez vous y rendre, vous pouvez utiliser le coupon “ADAM100” pour économiser £100 sur le billet d’entrée.

See ya!

When I started to really dig into my system to fully understand how it works, breaking everything to know of to fix it, I decided to do even worse and started using scm packages.

Scm packages download the source code directly for the upstream development repository using git, subversion, mercurial or whatever other vcs.

Doing this I ended up with a more-that-bleeding-edge system, causing a lot of breakages when stuff went incompatible with recent versions of other. That's perfect, since that's exactly the state I wanted to reach. If I wanted to recover a functional system, the easy solution that I adopted when I did not have much spare time was to revert my last changes and get back to an earlier version of the guilty package, but this was not the goal of the operation. What I really started to do at this point was to patch the broken stuff to make it compatible with the newer version of the guilty stuff which broke everything. It was sometimes really trivial, sometimes way less. I mostly did this for Gnome projects. It's a really good experience since you have to dig in a lot of projects and documentation, making you know better how various parts of your system work internally. Once I had everything back working, I then submitted my patches to the developers of the projects upstream, so that it gets fixed for everyone.

Now that I have way less spare time, I no longer have such a bleeding edge system, or at least I have way less scm packages. Sometimes I still need to patch stuff though, so I still use the same procedure.

My workflow

My workflow for contributing to upstream is not much different to the one I use for contributing to Exherbo. I also use an autopatch mechanism which is slightly different. My hook for automatically patch software is available there: https://github.com/Keruspe/paludis-config/blob/exherbo/hooks/ebuild_prepare_pre/patches.bash. If I remember correctly it was initially written by Ciaran McCreesh, the paludis's lead developer. When I want to patch something, I get a copy locally, I write and commit my patch, I generate a patch file and move it to /etc/paludis/autopatch/<category>/<package>/ where <category> is for example "x11-dri" and <package> is "mesa", according to exherbo's packages name. Each time I install a package, it applies all this patches before configuring and compiling the software. If it works, I submit it upstream, if not, I fix it and retry.

I highly recommend you to try contributing to open source projects, to fix or improve them, like adding new functionalities. The only risk is to learn a lot.

The goal of the init process

The init process is the most important software running on your system. Its goal is to start everything up in order for your system to work properly. It will manage everything, report errors (and maybe act regarding them) and supervise everything. When a process gets orphaned (because its father process, the one which started it, exits or dies), init will automatically become its father process.

The init process allows you to get a trace of what your processes are doing, where they do come from, and whether they’re in a decent or zombie state.

The legacy System V init

UNIX System V is probably the most known UNIX system. It was one of the most used operating systems in the 80s-90s for servers. Its init system is the base of most of our actual systems’ ones.

SysVInit design splits the boot process into several steps (usually 6 or 7 for recent versions) called “runlevels”:

• the runlevel 0 corresponds to the system shutdown
• the runlevel 1 corresponds to the “single user” mode, it’s the step when the system’s basic components are started
• the runlevel 2 corresponds to the “multi user” mode, all things that do not require networking are started there
• the runlevel 3 corresponds to the “multi user with network” mode, all things requiring networking are started there
• the runlevel 4 is usually unused, you can use it for specific custom purpose
• the runlevel 5 usually starts the graphical user interface, but a lot of distributions already does it in runlevel 3
• the runlevel 6 is used to reboot the system

Services that need to be started when you start the system must provide what is called an “init script” which will tell SysVInit how to start the said service. This is usually a bash script which takes as argument either start, stop or restart. If none is provided by upstream, you still can write your own one. You then assign these services to some runlevels, and they will be started in a random order when SysVInit will reach this runlevel. Usually they are started in alphabetical order so you can specify the order you want by prefixing the init scripts with a numerical value such as “03” or “99” so start in n early or late stage of this runlevel. Everything is done one after another, each task waits for the previous one to finish before starting.

In /etc/inittab, you specify which runlevel you want to reach by default at startup, so you can tell it to stop at runlevel 3 for example. You will be able later to run “init 5” to start everything for example. You also can run “init 6” which is equivalent to “reboot” or “init 0” which is equivalent to “shutdown now”

The new generation init systems

Here are four examples of alternatives to SysVInit. There are other but these are the most used.

OpenRC

OpenRC is Gentoo‘s init process. It is not a standalone one as it relies on SysVInit, it’s only there to add handy features and performance to SysVInit.

OpenRC allows you to explicitly specify dependencies between services, which makes the task a lot easier than having to prepend numbers to services names. It also adds the ability to get configuration files separated from init scripts.

Runit

Runit is a replacement to SysVInit that also handles runlevels. It is not compatible with the legacy ones, though. Runit splits the init process into three runlevels named “stages”:

• the stage 1 corresponds to the system initialization. If anything goes wrong here, runit drops you to a rescue shell.
• the stage 2 corresponds to everything that needs to be started (like SysVInit’s runlevel 5)
• the stage 3 corresponds to shutdown tasks.

Runit can read and handle SysVInit runlevels through an external compatibility layer called runsvdir but this is not how it is intended to be run.

Runit’s goal is to be as small and light as possible, it does exactly what you ask it to, and nothing more. You end up with a system as small as possible, but you do not have to forget anything since it won’t automatically do it for you.

Upstart

Upstart is an Ubuntu attempt to make the system boot faster. It is fully event-driven and hence only waits for stuff that needs to be waited for when it starts every process needed by the system. It allows to start all these processes in parallel making them wait for dependencies only once they need them. When a process fails or crashes, Upstart can handle this event to restart it automatically.

Upstart is fully compatible with SysVInit and the transition should be smooth and quite easy. Some software may need specific init scripts though, especially to take advantage of upstart features.

systemd

systemd (yes, no caps here) is Red Hat‘s attempt to make the boot smarter (and thus faster), especially for its desktop distribution: Fedora. systemd is widely inspired from Upstart, the Upstart’s TODO list, and from Apple’s Mac OS X init system: launchd.

systemd is as lazy as possible. It does not handle “runlevels” but rather “targets”. Everything handled by systemd is called a “unit”. A unit can either be a “target” (runlevel equivalent) or a “service” (the software itself), a “socket”, a “mount” operation, an “automount” operation or even a “timer” (cron-like) which will run your service in a regular fashion.

Some targets are provided by default but you can create your owns as you wish, with the names you want. You can specify which target has to be reached by default at system startup. In each unit, you can specify before or after which unit it should be started, whether it requires or is required by other units, if it conflicts with other units, and to which target it belongs. This allows systemd to know which targets and services it should start before starting the specified default target. To each target corresponds a target.wants directory, where the unit which should be started with this target are symbolic-linked. The sockets and mount operations are kinda more specific. Mount and automount operations are auto-generated from /etc/fstab (auto-mounting means that the filesystem appears to be mounted, but it really is mounted only once it has been accessed, which leads to a consequent gain of time). If a socket unit corresponds to a service one, systemd supports the socket activation of this service, which means that the service will really be started only when another service starts to communicate with it.

systemd is a real source of conflict between people against it and people in favor of it. The main argument of people which are against it is that it does too many things, it’s too complex and ships too many functionalities. I think this is a fake problem, since most of the functionalities are optional (and thus can be disabled), and everything is split into several binaries (systemd doesn’t do all this stuff itself but calls tools that it ships to do so). It is fully modular, and not modular like its “opponents”.

One of the interesting tools provided by systemd is the “journal”. The journal is basically a logging utility directly integrated in the init process (well, it actually only communicates with it, it’s not really in it). This allows you to get rid of an external logging utility such as syslog-ng or rsyslog. You can browse all the logs with the “journalctl” command which allows you to apply a lot of filters on them.

A really interesting serie of blog posts by Lennart Poettering (systemd’s lead developer) is available here.

We all agree: keeping an abstract layer in your code is something good, but it's often painful when you have to rewrite n-times some children having a similar implementation.
I always try to keep that children readable and fast understandable by making them one-liners. Adding a child becomes quite easy, even for a non-scala developer.

Trivial trait

Let's define a trait that will be the minimal representation of a message.

trait Message {
  def id: String
  def content: String
}

case class DefaultMessage(id: String, content: String) extends Message
case class FromToMessage(id: String, content: String, from: String, to: String) extends Message

No need for writing overriding methods. Actually, id and content parameters are defined as methods that implicitly override Message's methods. Nice, isn't it?

Trait using serialization

OK, that was quite simple. But how will you do if you have to create custom serializer object for each message type? In that example, we will be using the lift framework to (de)serialize JSON.

trait MessageSerializer[M <: Message] {
  implicit val format = DefaultFormats

  def apply(m: M): String = {
    Serialization.write(m)
  }

  def unapply(s: String)(implicit mf: Manifest[M]): Option[M] = {
    for {
      jvalue <- JsonParser.parseOpt(s)
      m <- jvalue.extractOpt[M]
    } yield m
  }
}

object DefaultMessageSerializer extends MessageSerializer[DefaultMessage]
object FromToMessageSerializer extends MessageSerializer[FromToMessage]

If you don't know what are apply and unapply methods, just take a look at this sample code to understand their usage:

/* implicit call to apply method */
val a = DefaultMessage("1234", "Hello world!")
println(DefaultMessageSerializer(a)) // print: {"id": "1234", "content": "Hello world!"}

/* implicit call to unapply method */
"""{"id": "5678", "content": "Love", "from": "me", "to": "you"}""" match {
  case FromToMessageSerializer(m) => println(m) // print FromToMessage("5678", "Love", "me", "you")
  case _ => println("error")
}