mirror of
https://github.com/kata-containers/kata-containers.git
synced 2025-10-22 12:29:49 +00:00
Add initial support for opentracing by using the `jaeger` package. Since opentracing uses the `context` package, add a `context.Context` as the first parameter to all the functions that we might want to trace. Trace "spans" (trace points) are then added by extracting the trace details from the specified context parameter. Notes: - Although the tracer is created in `main()`, the "root span" (aka the first trace point) is not added until `beforeSubcommands()`. This is by design and is a compromise: by delaying the creation of the root span, the spans become much more readable since using the web-based JaegerUI, you will see traces like this: ``` kata-runtime: kata-runtime create ------------ ------------------- ^ ^ | | Trace name First span name (which clearly shows the CLI command that was run) ``` Creating the span earlier means it is necessary to expand 'n' spans in the UI before you get to see the name of the CLI command that was run. In adding support, this became very tedious, hence my design decision to defer the creation of the root span until after signal handling has been setup and after CLI options have been parsed, but still very early in the code path. - At this stage, the tracing stops at the `virtcontainers` call boundary. - Tracing is "always on" as there doesn't appear to be a way to toggle it. However, its resolves to a "nop" unless the tracer can talk to a jaeger agent. Note that this commit required a bit of rework to `beforeSubcommands()` to reduce the cyclomatic complexity. Fixes #557. Signed-off-by: James O. D. Hunt <james.o.hunt@intel.com>
115 lines
3.5 KiB
Go
115 lines
3.5 KiB
Go
// Copyright (c) 2014,2015,2016,2017 Docker, Inc.
|
|
// Copyright (c) 2018 Huawei Corporation.
|
|
//
|
|
// SPDX-License-Identifier: Apache-2.0
|
|
//
|
|
|
|
package main
|
|
|
|
import (
|
|
"encoding/json"
|
|
"fmt"
|
|
"io/ioutil"
|
|
"os"
|
|
|
|
"github.com/opencontainers/runc/libcontainer/specconv"
|
|
opentracing "github.com/opentracing/opentracing-go"
|
|
"github.com/urfave/cli"
|
|
)
|
|
|
|
var specCLICommand = cli.Command{
|
|
Name: "spec",
|
|
Usage: "create a new specification file",
|
|
ArgsUsage: "",
|
|
Description: `The spec command creates the new specification file named "` + specConfig + `" for
|
|
the bundle.
|
|
|
|
The spec generated is just a starter file. Editing of the spec is required to
|
|
achieve desired results. For example, the newly generated spec includes an args
|
|
parameter that is initially set to call the "sh" command when the container is
|
|
started. Calling "sh" may work for an ubuntu container or busybox, but will not
|
|
work for containers that do not include the "sh" program.
|
|
|
|
EXAMPLE:
|
|
To run docker's hello-world container one needs to set the args parameter
|
|
in the spec to call hello. This can be done using the sed command or a text
|
|
editor. The following commands create a bundle for hello-world, change the
|
|
default args parameter in the spec from "sh" to "/hello", then run the hello
|
|
command in a new hello-world container named container1:
|
|
|
|
mkdir hello
|
|
cd hello
|
|
docker pull hello-world
|
|
docker export $(docker create hello-world) > hello-world.tar
|
|
mkdir rootfs
|
|
tar -C rootfs -xf hello-world.tar
|
|
kata-runtime spec
|
|
sed -i 's;"sh";"/hello";' ` + specConfig + `
|
|
kata-runtime run container1
|
|
|
|
In the run command above, "container1" is the name for the instance of the
|
|
container that you are starting. The name you provide for the container instance
|
|
must be unique on your host.
|
|
|
|
An alternative for generating a customized spec config is to use "oci-runtime-tool", the
|
|
sub-command "oci-runtime-tool generate" has lots of options that can be used to do any
|
|
customizations as you want, see runtime-tools (https://github.com/opencontainers/runtime-tools)
|
|
to get more information.
|
|
|
|
When starting a container through kata-runtime, kata-runtime needs root privilege. If not
|
|
already running as root, you can use sudo to give kata-runtime root privilege. For
|
|
example: "sudo kata-runtime start container1" will give kata-runtime root privilege to start the
|
|
container on your host.
|
|
|
|
Alternatively, you can start a rootless container, which has the ability to run
|
|
without root privileges. For this to work, the specification file needs to be
|
|
adjusted accordingly. You can pass the parameter --rootless to this command to
|
|
generate a proper rootless spec file.`,
|
|
Flags: []cli.Flag{
|
|
cli.StringFlag{
|
|
Name: "bundle, b",
|
|
Value: "",
|
|
Usage: "path to the root of the bundle directory",
|
|
},
|
|
},
|
|
Action: func(context *cli.Context) error {
|
|
ctx, err := cliContextToContext(context)
|
|
if err != nil {
|
|
return err
|
|
}
|
|
|
|
span, _ := opentracing.StartSpanFromContext(ctx, "spec")
|
|
defer span.Finish()
|
|
|
|
spec := specconv.Example()
|
|
|
|
checkNoFile := func(name string) error {
|
|
_, err := os.Stat(name)
|
|
if err == nil {
|
|
return fmt.Errorf("File %s exists. Remove it first", name)
|
|
}
|
|
if !os.IsNotExist(err) {
|
|
return err
|
|
}
|
|
return nil
|
|
}
|
|
bundle := context.String("bundle")
|
|
if bundle != "" {
|
|
if err := os.Chdir(bundle); err != nil {
|
|
return err
|
|
}
|
|
}
|
|
if err := checkNoFile(specConfig); err != nil {
|
|
return err
|
|
}
|
|
data, err := json.MarshalIndent(spec, "", "\t")
|
|
if err != nil {
|
|
return err
|
|
}
|
|
if err := ioutil.WriteFile(specConfig, data, 0640); err != nil {
|
|
return err
|
|
}
|
|
return nil
|
|
},
|
|
}
|