Convert Figma logo to code with AI

goss-org logogoss

Quick and Easy server testing/validation

5,565
472
5,565
55

Top Related Projects

5,563

Quick and Easy server testing/validation

Terratest is a Go library that makes it easier to write automated tests for your infrastructure code.

validate the structure of your container images

10,221

Dockerfile linter, validate inline bash, written in Haskell

2,846

InSpec: Auditing and Testing Framework

Bash Automated Testing System

Quick Overview

Goss is a YAML-based serverspec alternative tool for validating a server's configuration. It allows users to define server tests in a simple YAML format and execute them quickly, making it ideal for both local development and CI/CD pipelines. Goss is designed to be fast, easy to use, and highly portable.

Pros

  • Simple YAML-based test definitions
  • Fast execution time
  • Portable and easy to integrate into CI/CD pipelines
  • Supports multiple output formats (JSON, JUnit, TAP)

Cons

  • Limited compared to more comprehensive testing frameworks
  • Primarily focused on server configuration testing
  • May require additional tools for complex scenarios
  • Documentation could be more extensive

Code Examples

  1. Basic server test:
port:
  tcp:80:
    listening: true
    ip:
    - 0.0.0.0
file:
  /etc/passwd:
    exists: true
    mode: "0644"
    owner: root
    group: root
    filetype: file

This example checks if port 80 is listening and verifies the properties of the /etc/passwd file.

  1. Process check:
process:
  nginx:
    running: true

This example checks if the nginx process is running.

  1. Package installation check:
package:
  nginx:
    installed: true
    versions:
    - 1.18.0

This example verifies that nginx is installed and checks its version.

Getting Started

  1. Install Goss:
curl -L https://github.com/goss-org/goss/releases/latest/download/goss-linux-amd64 -o /usr/local/bin/goss
chmod +rx /usr/local/bin/goss
  1. Create a test file (e.g., goss.yaml):
file:
  /etc/hosts:
    exists: true
    mode: "0644"
    owner: root
    group: root
  1. Run the test:
goss validate

This will execute the tests defined in goss.yaml and display the results.

Competitor Comparisons

5,563

Quick and Easy server testing/validation

Pros of goss

  • Actively maintained with regular updates and bug fixes
  • Extensive documentation and community support
  • Wide range of validation types for system testing

Cons of goss

  • Learning curve for complex configurations
  • Limited built-in support for cloud-native environments

Code comparison

goss:

file:
  /etc/passwd:
    exists: true
    mode: "0644"
    owner: root
    group: root
    filetype: file
    contains: []

There is no code comparison available for this case, as both repositories (goss-org/goss and goss-org/goss) refer to the same project. The code structure and usage would be identical.

Summary

Goss is a YAML-based serverspec alternative tool for validating a server's configuration. It allows users to define system tests in a simple, human-readable format. The project is actively maintained and has a strong community following. While it offers extensive functionality for traditional server environments, it may require additional setup for cloud-native scenarios. The learning curve can be steep for complex configurations, but the comprehensive documentation helps mitigate this issue.

Terratest is a Go library that makes it easier to write automated tests for your infrastructure code.

Pros of Terratest

  • Supports multiple cloud providers and infrastructure tools (AWS, Azure, GCP, Kubernetes, Terraform, Packer, etc.)
  • Provides a comprehensive testing framework for infrastructure code
  • Allows writing tests in Go, offering more flexibility and power for complex scenarios

Cons of Terratest

  • Steeper learning curve, especially for those not familiar with Go programming
  • Longer test execution times due to the nature of infrastructure testing
  • Requires more setup and configuration compared to Goss

Code Comparison

Goss (YAML configuration):

file:
  /etc/passwd:
    exists: true
    mode: "0644"
    owner: root
    group: root

Terratest (Go code):

package test

import (
    "testing"
    "github.com/gruntwork-io/terratest/modules/terraform"
    "github.com/stretchr/testify/assert"
)

func TestTerraformExample(t *testing.T) {
    terraformOptions := &terraform.Options{
        TerraformDir: "../examples/terraform-aws-example",
    }

    defer terraform.Destroy(t, terraformOptions)
    terraform.InitAndApply(t, terraformOptions)

    output := terraform.Output(t, terraformOptions, "instance_id")
    assert.NotEmpty(t, output)
}

While Goss focuses on system validation using simple YAML configurations, Terratest provides a more comprehensive approach to testing infrastructure code using Go, allowing for more complex scenarios and integration with various cloud providers and tools.

validate the structure of your container images

Pros of container-structure-test

  • Native integration with Google Cloud Build and other Google Cloud services
  • Supports multiple test file formats (YAML, JSON, and Go)
  • Extensive documentation and examples provided by Google

Cons of container-structure-test

  • Limited to container testing, while Goss can test both containers and host systems
  • Less frequent updates and community contributions compared to Goss
  • Steeper learning curve for users not familiar with Google Cloud ecosystem

Code Comparison

container-structure-test example:

schemaVersion: '2.0.0'
commandTests:
  - name: "Check Python version"
    command: "python"
    args: ["--version"]
    expectedOutput: ["Python 3."]

Goss example:

command:
  python --version:
    exit-status: 0
    stdout:
    - /Python 3./
    stderr: []
    timeout: 10000

Both tools allow for testing command outputs, but Goss provides a more concise syntax and additional options like timeout and stderr checking. container-structure-test offers a more structured approach with explicit schema versioning and command arguments separation.

While container-structure-test is tailored for container testing within the Google Cloud ecosystem, Goss offers more flexibility for various testing scenarios and environments. The choice between the two depends on specific project requirements and the preferred testing ecosystem.

10,221

Dockerfile linter, validate inline bash, written in Haskell

Pros of Hadolint

  • Specialized for Dockerfile linting, offering more focused and in-depth analysis
  • Integrates with popular CI/CD tools and editors for seamless workflow integration
  • Provides best practices and security recommendations specific to Docker

Cons of Hadolint

  • Limited to Dockerfile analysis, while Goss can validate various system components
  • May require more setup and configuration for complex Dockerfile scenarios
  • Less flexible for general system testing and validation

Code Comparison

Hadolint (Dockerfile linting):

FROM ubuntu:18.04
RUN apt-get update && apt-get install -y python
COPY . /app
CMD ["python", "app.py"]

Goss (system testing):

file:
  /etc/passwd:
    exists: true
    mode: "0644"
    owner: root
    group: root
    filetype: file

Hadolint focuses on Dockerfile best practices and syntax, while Goss allows for broader system component validation. Hadolint excels in Docker-specific linting, whereas Goss offers more versatility in testing various aspects of system configuration and state.

2,846

InSpec: Auditing and Testing Framework

Pros of InSpec

  • More comprehensive testing capabilities, including support for cloud infrastructure
  • Larger community and ecosystem with extensive resources and integrations
  • Ruby-based DSL allows for more complex and flexible test definitions

Cons of InSpec

  • Steeper learning curve due to its more complex DSL and broader scope
  • Slower execution compared to Goss's lightweight approach
  • Requires Ruby runtime, which may not be available in all environments

Code Comparison

Goss (YAML-based):

file:
  /etc/passwd:
    exists: true
    mode: "0644"
    owner: root
    group: root

InSpec (Ruby-based):

describe file('/etc/passwd') do
  it { should exist }
  its('mode') { should cmp '0644' }
  its('owner') { should eq 'root' }
  its('group') { should eq 'root' }
end

Both Goss and InSpec are infrastructure testing tools, but they differ in complexity and scope. Goss focuses on simplicity and speed, using YAML for test definitions, while InSpec offers a more powerful Ruby-based DSL for comprehensive testing across various platforms and cloud environments. Goss is ideal for quick, lightweight tests, whereas InSpec is better suited for complex, enterprise-level infrastructure validation.

Bash Automated Testing System

Pros of Bats-core

  • Written in Bash, making it highly portable and easy to integrate into existing shell scripts
  • Supports parallel test execution, improving performance for large test suites
  • Provides a TAP-compliant output format, enabling integration with various CI/CD tools

Cons of Bats-core

  • Limited to testing Bash scripts and shell commands, less versatile for system-wide testing
  • Requires more manual setup and configuration compared to Goss's declarative approach
  • May be more challenging to write and maintain complex test scenarios

Code Comparison

Bats-core test example:

@test "addition using bc" {
  result="$(echo 2+2 | bc)"
  [ "$result" -eq 4 ]
}

Goss test example:

file:
  /etc/passwd:
    exists: true
    mode: "0644"
    owner: root
    group: root

Summary

Bats-core excels in testing Bash scripts and shell commands, offering portability and integration with existing shell environments. It's particularly useful for projects heavily reliant on shell scripting. Goss, on the other hand, provides a more comprehensive system testing approach with its YAML-based configuration and broader scope of testable resources. The choice between the two depends on the specific testing requirements and the nature of the system or application being tested.

Convert Figma logo designs to code with AI

Visual Copilot

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

Goss - Quick and Easy server validation

Build Status Github All Releases Documentation Status ** Blog

Goss in 45 seconds

asciicast

Note: For testing containers see the dgoss wrapper. Also, user submitted wrapper scripts for Kubernetes kgoss and Docker Compose dcgoss.

Note: For some Docker/Kubernetes healthcheck, health endpoint, and container ordering examples, see my blog post here.

Introduction

What is Goss?

Goss is a YAML based serverspec alternative tool for validating a server's configuration. It eases the process of writing tests by allowing the user to generate tests from the current system state. Once the test suite is written they can be executed, waited-on, or served as a health endpoint.

Why use Goss?

  • Goss is EASY! - Goss in 45 seconds
  • Goss is FAST! - small-medium test suites are near instantaneous, see benchmarks
  • Goss is SMALL! - <10MB single self-contained binary

Installation

Note: For macOS and Windows, see: platform-feature-parity.

This will install goss and dgoss.

Note: Using curl | sh is not recommended for production systems, use manual installation below.

# Install latest version to /usr/local/bin
curl -fsSL https://goss.rocks/install | sh

# Install v0.4.8 version to ~/bin
curl -fsSL https://goss.rocks/install | GOSS_VER=v0.4.8 GOSS_DST=~/bin sh

Manual installation

Latest

curl -L https://github.com/goss-org/goss/releases/latest/download/goss-linux-amd64 -o /usr/local/bin/goss
chmod +rx /usr/local/bin/goss

curl -L https://github.com/goss-org/goss/releases/latest/download/dgoss -o /usr/local/bin/dgoss
# Alternatively, using the latest master
# curl -L https://raw.githubusercontent.com/goss-org/goss/master/extras/dgoss/dgoss -o /usr/local/bin/dgoss
chmod +rx /usr/local/bin/dgoss

Specific Version

# See https://github.com/goss-org/goss/releases for release versions
VERSION=v0.4.8
curl -L "https://github.com/goss-org/goss/releases/download/${VERSION}/goss-linux-amd64" -o /usr/local/bin/goss
chmod +rx /usr/local/bin/goss

# (optional) dgoss docker wrapper (use 'master' for latest version)
VERSION=v0.4.8
curl -L "https://github.com/goss-org/goss/releases/download/${VERSION}/dgoss" -o /usr/local/bin/dgoss
chmod +rx /usr/local/bin/dgoss

Build it yourself

make build

Full Documentation

Full Documentation

Using the container image

Using the Goss container image

Quick start

Writing a simple sshd test

An initial set of tests can be derived from the system state by using the add or autoadd commands.

Let's write a simple sshd test using autoadd.

# Running it as root will allow it to also detect ports
$ sudo goss autoadd sshd

Generated goss.yaml:

port:
  tcp:22:
    listening: true
    ip:
    - 0.0.0.0
  tcp6:22:
    listening: true
    ip:
    - '::'
service:
  sshd:
    enabled: true
    running: true
user:
  sshd:
    exists: true
    uid: 74
    gid: 74
    groups:
    - sshd
    home: /var/empty/sshd
    shell: /sbin/nologin
group:
  sshd:
    exists: true
    gid: 74
process:
  sshd:
    running: true

Now that we have a test suite, we can:

  • Run it once
$ goss validate
...............

Total Duration: 0.021s # <- yeah, it's that fast..
Count: 15, Failed: 0
  • Edit it to use templates, and run with a vars file
goss --vars vars.yaml validate
  • keep running it until the system enters a valid state or we timeout
goss validate --retry-timeout 30s --sleep 1s
  • serve the tests as a health endpoint
$ goss serve &
$ curl localhost:8080/healthz

# JSON endpoint
$ goss serve --format json &
$ curl localhost:8080/healthz

# rspecish response via content negotiation
$ goss serve --format json &
$ curl -H "Accept: application/vnd.goss-rspecish" localhost:8080/healthz

Manually editing Goss files

Goss files can be manually edited to improve readability and expressiveness of tests.

A Json draft 7 schema available at https://goss.rocks/schema.yaml makes it easier to edit simple goss.yaml files in IDEs, providing usual coding assistance such as inline documentation, completion and static analysis. See #793 for screenshots.

For example, to configure the Json schema in JetBrains intellij IDEA, follow documented instructions, with arguments such as:

  • schema url=https://goss.rocks/schema.yaml
  • schema version=Json schema version 7
  • file path pattern=*/goss.yaml

In addition, Goss files can also be further manually edited (without yet full json support) to use:

Some examples:

user:
  sshd:
    title: UID must be between 50-100, GID doesn't matter. home is flexible
    meta:
      desc: Ensure sshd is enabled and running since it's needed for system management
      sev: 5
    exists: true
    uid:
      # Validate that UID is between 50 and 100
      and:
        gt: 50
        lt: 100
    home:
      # Home can be any of the following
      or:
      - /var/empty/sshd
      - /var/run/sshd

package:
  kernel:
    installed: true
    versions:
      # Must have 3 kernels and none of them can be 4.4.0
      and:
      - have-len: 3
      - not:
          contain-element: 4.4.0

  # Loaded from --vars YAML/JSON file
  {{.Vars.package}}:
    installed: true

{{if eq .Env.OS "centos"}}
  # This test is only when $OS environment variable is set to "centos"
  libselinux:
    installed: true
{{end}}

Goss.yaml files with templates can still be validated through the Json schema after being rendered using the goss render command. See example below

$ cd docs
$ goss --vars ./vars.yaml render > rendered_goss.yaml
# proceed with json schema validation of rendered_goss.yaml in your favorite IDE
# or in one of the Json schema validator listed in https://json-schema.org/implementations.html
# The following example is for a Linux AMD64 host
$ curl -LO https://github.com/neilpa/yajsv/releases/download/v1.4.1/yajsv.linux.amd64
$ chmod a+x yajsv.linux.amd64
$ sudo mv yajsv.linux.amd64 /usr/sbin/yajsv

$ yajsv -s goss-json-schema.yaml rendered_goss.yaml

rendered_goss.yaml: fail: process.chrome: skip is required
rendered_goss.yaml: fail: service.sshd: skip is required
1 of 1 failed validation
rendered_goss.yaml: fail: process.chrome: skip is required
rendered_goss.yaml: fail: service.sshd: skip is required

Full list of available Json schema validators can be found in https://json-schema.org/implementations.html#validator-command%20line

Supported resources

  • package - add new package
  • file - add new file
  • addr - add new remote address:port - ex: google.com:80
  • port - add new listening [protocol]:port - ex: 80 or udp:123
  • service - add new service
  • user - add new user
  • group - add new group
  • command - add new command
  • dns - add new dns
  • process - add new process name
  • kernel-param - add new kernel-param
  • mount - add new mount
  • interface - add new network interface
  • http - add new network http url with proxy support
  • goss - add new goss file, it will be imported from this one
  • matching - test for matches in supplied content

Supported output formats

  • rspecish - (default) Similar to rspec output
  • documentation - Verbose test results
  • json - JSON, detailed test result
  • tap - TAP style
  • junit - JUnit style
  • nagios - Nagios/Sensu compatible output /w exit code 2 for failures.
  • prometheus - Prometheus compatible output.
  • silent - No output. Avoids exposing system information (e.g. when serving tests as a healthcheck endpoint).

Community Contributions

  • goss-ansible - Ansible module for Goss.
  • degoss - Ansible role for installing, running, and removing Goss in a single go.
  • kitchen-goss - A test-kitchen verifier plugin for Goss.
  • goss-fpm-files - Might be useful for building goss system packages.
  • packer-provisioner-goss - A packer plugin to run Goss as a provision step.
  • gossboss - Collect and view aggregated Goss test results from multiple remote Goss servers.

Limitations

goss works well on Linux, but support on Windows & macOS is alpha. See platform-feature-parity.

The following tests have limitations.

Package:

  • rpm
  • deb
  • Alpine apk
  • pacman

Service:

  • systemd
  • sysV init
  • OpenRC init
  • Upstart