Skip to content

Latest commit

 

History

History
167 lines (128 loc) · 4.45 KB

basic_usage.md

File metadata and controls

167 lines (128 loc) · 4.45 KB
Raw

Basic Usage

Build and Deploy Nanos Unikernel

For a more thorough set of examples for your preferred language or framework check out our examples repo.

Golang Example

Create a file called main.go with the content below:

package main

import "fmt"

func main() {
	fmt.Println("Hello World!")
}

Build it:

$ GOOS=linux go build main.go

Package and deploy:

$ ops run main

For more examples using Golang, visit our examples repository.

PHP Example

Create a file called ex.php with the content below:

<?php
phpinfo();
?>

Package and deploy:

$ ops pkg load eyberg/php:7.2.13 -a ex.php

NodeJS Example

Create a file called ex.js with the content below:

console.log("Hello World!");

Package and deploy:

$ ops pkg load eyberg/node:20.5.0 -a ex.js

You should see "Hello World!" printed on your screen and then the ops command exits. For more examples using NodeJS, visit our examples repository.

Run and Pass an Environment Variable

This can be done via the configuration file but if you want to dynamically inject without having to rely on the configuration file this is the way:

package main

import (
	"fmt"
	"os"
	"strings"
)

func main() {

	fmt.Println("FOO:", os.Getenv("FOO"))
	fmt.Println("BAR:", os.Getenv("BAR"))

	fmt.Println()
	for _, e := range os.Environ() {
		pair := strings.SplitN(e, "=", 2)
		fmt.Println(pair[0])
	}
}
$ GOOS=linux go build
$ ops run -e FOO=1 tea

Load vs Run

While both of these commands are used to execute code, there is a big difference when you would choose to run one rather than the other. For ops run, you would use this command to run compiled code (executable machine code). So, for example, any golang code that you may run, you would use this command. Any code that is compiled at runtime, you would use ops pkg load. Example of languages where you would use this are NodeJS or PHP. Each supported language for ops pkg load, will have a corresponding package. To see a list of available packages, run ops pkg list.

Nightly vs. Main

Right now we have two release channels. If you run ops as is you are tracking the main release channel. There is no update frequency associated with it just whenever we deem significant work has been done and we are not horribly breaking anything.

The other channel you can track is the nightly channel. This is populated every night via the build system with whatever is in master. So if you want bleeding edge you can utilize that.

The magic incantation for tracking this channel is simply to switch the -n or --nightly flag on.

For example:

$ ops -n run main

If there are already cached images you can use the --force or -f flag to replace them with the lastest images from a given channel. For example, the following command will both track the nightly channel and replace any cached images with the lastest from that channel:

$ ops -nf run main

You may also specify a recent git commit from the Nanos repo. For instance if you want to try a new feature from a PR you can set the short git commit like via '--nanos-version' like so:

ops pkg load eyberg/node:20.5.0 --nanos-version=3c1fb76

OPS itself also tracks nightly builds:

https://storage.googleapis.com/cli/linux/release/nightly/ops https://storage.googleapis.com/cli/darwin/arm64/release/nightly/ops

You can also check the md5 of any download by using the .md5 suffix:

https://storage.googleapis.com/cli/linux/release/nightly/ops-linux-nightly.md5

Supported Operating Systems

OPS can run on many different Unix based environments.

  • MacOS
  • Debian
  • Ubuntu
  • Arch
  • Fedora
  • Centos
  • WSL2

Libc

OPS supports whatever libc you wish to utilize. Well over 99% of our users, customers and packages will default to glibc as that is what the vast majority of applications are linked to today. However other alt-libcs such as MUSL are supported. They come with the same/similar caveats that one might find when utilizing them on Linux.