Packages
Packages are officially supported images with pre-compiled languages (ie nodejs and php) or applications (ie Redis and Nginx). This makes it easier and more convenient to execute code without needing to compile your own interpreter(s).
You can also create and upload your own public and private packages at https://repo.ops.city as well.
Listing Packages
To get a list of currently supported packages, run the following command:
The package list can also be searched by simply providing a regular expression to the list
command's --search
option (-s
for short).
Note: This command will probably go away in the future in favor of search.
Getting package locally
Package can be downloaded to the local cache ~/.ops/packages
using ops get
command.
Not sure what the latest package version would be? You can just grab the latest by substituting the version with the ':latest' tag:
Information of Package
Package description provides common assumptions and settings required for running your application with help of package. You can get package description using ops pkg describe <package_name>
command.
Contents of Package
If you want see contents of a package, you can use ops pkg contents <package_name>
command.
Removing local packages
By default, downloaded packages are stored in ~/.ops/bin/.packages
. If you'd like to remove a package from your hard drive, whether its to conserve space, or to force a re-download of the package, you can do it here utilizing the rm
cli tool.
Creating a Custom or Local Dev packages
If you want to create a packaeg manually you can follow these instructions:
https://github.com/nanovms/ops/blob/master/PACKAGES.md
then copy over an un-tarred dir to ~/.ops/local_packages
Finally you can run it via the local flag:
You can use the --missing-files flag on 'ops run' to hunt down any missing shared libraries that might not be getting loaded from the ldd output. For example with ruby:
You can also turn on '--trace' to find the locations it might be in. A common idiom would to be run:
then grep through the output to find loads that failed.
If you wish to create your own local package you can use this as a template with your program being 'test':
At a minimum your package.manifest should have the following fields:
It is important to note that the Program path should be valid. If you wish you may also add Language, Runtime, Description into the manifest so they show up in the search.
These have been traditionally populated from ~/.ops/packages/manifest.json . You may also wish to include a README.md inside the package.
Then we can directly add the package in question as we develop on it:
We can finally load the package:
Create a Cloud Image from Local Package
Creating a cloud image from your local package is just like creating it from a regular package but you pass the '-l' flag in:
Create a New Package from an existing Package
You can use an existing package as a base to create a new package. For instance if you are deploying a node application you might have something that looks like this:
You can create a new package from this config like so:
and use it:
Then you can upload it to https://repo.ops.city:
Create a Package from Docker
You can create a local package from an existing docker container. If the container does not exist it will download it first and then convert it into a unikernel. Currently this just grabs the binary and libraries necessary to run it versus the entire filesystem that might be present.
If you would like to create a package from a local image try this workflow:
Sample Dockerfile:
Note: Right now the build process is dependent upon a non-scratch environment, for instance using ldd and cut.
Create a Package from 'ops run' style
You can create a local package in the same style you use ops run
by using ops pkg from-run
Login to the OPS Repo
To upload private and public packages or use your private packages:
You'll need to initially create an account at https://repo.ops.city . For now it just relies on github auth:
Upload a Package
If you have an account from the above step you can login with your apikey:
Then, for example, you could create a new node package from docker and then push it up:
Search
You can search for a pakage on https://repo.ops.city like so:
Then intention is that this will eventually deprecate 'ops pkg list'.
Debugging
When working with scripting languages you might run into issues where they load libraries at run-time that you aren't aware you need. There are two ways to identify these:
You can turn on --trace with ops to look for it loading libraries:
You can use strace and run it normally and look for explicit dlopen calls:
Once you find the missing library you can create the proper directory in your package and copy it in or put it into a local directory structure if just using 'ops run'.
Manual Tips:
If you have a large number of libraries to copy you may try something like this:
Another useful way of doing this is like so:
Note: You may wish to replace any symlinks with copies of those files using something like:
Last updated