cloudposse / geodesic

🚀 Geodesic is a DevOps Linux Toolbox in Docker

Geodesic is a robust Linux toolbox container, crafted to optimize DevOps workflows. This container comes fully loaded with all essential dependencies for a complete DevOps toolchain. It's designed to bring consistency and boost efficiency across development environments. It achieves this without the need for installing additional software on your workstation. Think of Geodesic as a containerized parallel to Vagrant, offering similar functionality within a Docker container context.

Key Features

• Unified Toolchain: By packaging all necessary DevOps tools and dependencies, Geodesic eliminates the "works on my machine" problem, ensuring toolchain uniformity across different machines.
• Consistent Environment: Geodesic guarantees that every developer operates in a uniform OS environment with consistent tool versions, sidestepping discrepancies that often arise in diverse development setups.
• Quick Start for New Developers: It streamlines the onboarding process for new team members, allowing them to bypass lengthy workstation configurations and dive straight into productivity.
• Cross-Platform Compatibility: With native support for Mac OSX, Linux, and Windows (via WSL), Geodesic extends its versatile toolchain to a wide range of operating systems, ensuring broad accessibility and functionality.
• Version Control for Tools: Geodesic facilitates easy versioning of tools for different environments, enabling repeatable setups and minimizing compatibility issues.
• Reusable Base Image for Toolboxes: Empower teams to create and maintain consistent toolbox images, ensuring a standardized development environment across the board.

Screenshots

Example of running a shell based on the cloudposse/geodesic base docker image.

---

Note

This project is part of Cloud Posse's comprehensive "SweetOps" approach towards DevOps.

Learn More

It's 100% Open Source and licensed under the APACHE2.

Introduction

These days, the typical software application is distributed as a docker image and run as a container. Why should infrastructure be any different? Since everything we write is "Infrastructure as Code", we believe that it should be treated the same way. This is the "Geodesic Way". Use containers+envs instead of unconventional wrappers, complicated folder structures and symlink hacks. Geodesic is the container for all your infrastructure automation needs that enables you to truly achieve SweetOps.

Geodesic is best used in one of these two ways:

1. Interactive Shell It is optimized to work as an interactive command-line shell. The shell includes the ultimate mashup of cloud orchestration tools all distributed through our packages. Installation of the shell is as easy as running a docker container or using it as a base image for your own Docker toolbox.
2. Docker Base Image You can create your own Dockerfile and use cloudposse/geodesic as the base image. This way you can rapidly bring up consistent toolboxes.

An organization may chose to leverage all of these components, or just the parts that make their life easier.

We recommend starting by using geodesic as a Docker base image (e.g. FROM cloudposse/geodesic:... pinned to a release and base OS) in your projects.

Important

Note: Starting with Geodesic 2.0, we distribute Geodesic as a multi-platform (linux/amd64, linux/arm64) Debian-based Docker image and a single-platform (linux/amd64) Alpine-based image. We recommend the Debian-based image; consequently the cloudposse/geodesic:latest Docker image tag now points to it. (Previously cloudposse/geodesic:latest referred to the Alpine image.) The Alpine version is deprecated and we make no promises about future support for it.

What’s New in Geodesic 2.0

Geodesic 2.0 introduces support for Apple Silicon (M1 and later chips), and prioritizes Debian over Alpine as the base OS. Users new to Geodesic should use the Debian-based version and existing users of the Alpine-based image should switch to the Debian-based image as soon as is convenient. They each have nearly all the same tools pre-installed, so switching is mainly a matter of updating how you customize it, replacing Alpine packages with Debian packages.

In order for a tool to be included in Geodesic 2.0, it must be available as both a linux/amd64 and linux/arm64 binary. (In exceptional cases, if a tool is written in the go language and distributes source code only, Cloud Posse may build the needed binaries.) A few tools that were in Geodesic 1.0 had not yet been updated to provide linux/arm64 binaries and were omitted from Geodesic 2.0. (See the Geodesic 2.0 Release Notes for details on which tools were removed.)

Docker Tags and Their Evolution

Geodesic Docker images are tagged with VERSION-BASE_OS, e.g. 2.0.0-debian or 2.0.0-alpine. The latest tag points to the latest Debian-based image, although we recommend pinning to a specific version.

• Prior to Geodesic 2.0, the latest tag pointed to the latest Alpine-based image.
• Prior to Geodesic 0.138.0, all Docker images were based on Alpine only and simply tagged VERSION.

Want to learn more? Check out our getting started with Geodesic guide!

Usage

Quickstart

docker run

Launching Gedoesic is a bit complex, so we recommend you install a launch script by running

docker run --rm cloudposse/geodesic:latest-debian init | bash

After that, you should be able to launch Geodesic just by typing

geodesic

Customizing your Docker image

In general we recommend creating a customized version of Geodesic by creating your own Dockerfile starting with

ARG VERSION=2.0.0
ARG OS=debian
FROM cloudposse/geodesic:$VERSION-$OS

# Add configuration options such as setting a custom BANNER,
# setting the initial AWS_PROFILE and AWS_DEFAULT_REGION, etc. here

ENV BANNER="my-custom-geodesic"

You can see some example configuration options to include in Dockerfile.options.

Multi-platform gotchas

Although the Geodesic base image is provided in 2 architectures, when you do a local build of your custom image, it will, by default, only be built for the architecture of the machine you are building on. This is fine until you want to share it. You need to be aware that if you push just the image you built with docker build you will only be supporting a single architecture. You should use docker buildx to build a multi-platform image and push it to a Docker repository for sharing.

If you intend to support both architectures, you need to be sure that any customizations you install are properly installed for both architectures. Package managers handle this for you automatically, but if you are downloading files directly, you need to be careful to select the right one. See the use of TARGETARCH in Dockerfile.debian for some examples.

Adding packages

You can also add extra commands by installing "packages". Both Debian and Alpine have a large selection of packages to choose from. Cloud Posse also provides a large set of packages for installing common DevOps commands and utilities via cloudposse/packages, but linux/arm64 packages are only provided for Debian, not Alpine. The package repositories are pre-installed in Geodesic, all you need to do is add the packages you want via RUN commands in your Dockerfile. Debian will automatically select the correct architecture for the package.

Installing packages in Debian

Debian uses apt for package management and we generally recommend using the apt-get command to install packages. In addition to the default repositories, Geodesic pre-installs the Cloud Posse package repository and the Google Cloud SDK package repository. Unlike with apk, you do not need to specify a package repository when installing a package because all repositories will be searched for it. Also unlike apk, apt-get does not let you specify a version range on the command line, but they do allow wildcards. Package versions include a release number (typically "1") at the end, to allow for updated packages when there is a bug in the package itself. Therefore, best practice is to use a wildcard for the release number when specifying a package version. For example, to install the Google Cloud SDK at a version 300.0.0:

RUN apt-get update && apt-get install -y google-cloud-sdk="300.0.0-*"

Note the -y flag to apt-get install. That is required for scripted installation, otherwise the command will ask for confirmation from the keyboard before installing a package.

Installing packages in Alpine

Under Alpine, you install a package by specifying a package name and a repository label (if not the default repository). (You can also specify a version, see the Alpine documentation for details). In addition to the default package repository, Geodesic installs 3 others:

Repository Label	Repository Name
@testing	edge/testing
@community	edge/community
@cloudposse	cloudposse/packages

As always, because of Docker layer caching, you should start your command line by updating the repo indexes, and then add your packages. Alpine uses apk. So, to install Teleport support from the Cloud Posse package repository, pinned to version 4.2.x (which is the last to support Alpine), we can add this to our Dockerfile:

RUN apk update && apk add -u teleport@cloudposse=~4.2

Customizing your shell at launch time

After you have built your Docker image, or if you are using a shared Docker image, you can add further customization at launch time. When Geodesic starts up, it looks for customization scripts and configuration so you can do things like add command aliases or override preconfigured options. Detailed information about launch-time configuration is in the customization document, available from within the shell via man customization.

Related Projects

Check out these related projects.

• Packages - Cloud Posse installer and distribution of native apps
• Build Harness - Collection of Makefiles to facilitate building Golang projects, Dockerfiles, Helm charts, and more
• terraform-aws-components - Catalog of reusable Terraform components and blueprints for provisioning reference architectures

✨ Contributing

This project is under active development, and we encourage contributions from our community. Many thanks to our outstanding contributors:

🐛 Bug Reports & Feature Requests

Please use the issue tracker to report any bugs or file feature requests.

💻 Developing

If you are interested in being a contributor and want to get involved in developing this project or help out with Cloud Posse's other projects, we would love to hear from you! Hit us up in Slack, in the #cloudposse channel.

In general, PRs are welcome. We follow the typical "fork-and-pull" Git workflow.

1. Review our Code of Conduct and Contributor Guidelines.
2. Fork the repo on GitHub
3. Clone the project to your own machine
4. Commit changes to your own branch
5. Push your work back up to your fork
6. Submit a Pull Request so that we can review your changes

NOTE: Be sure to merge the latest changes from "upstream" before making a pull request!

🌎 Slack Community

Join our Open Source Community on Slack. It's FREE for everyone! Our "SweetOps" community is where you get to talk with others who share a similar vision for how to rollout and manage infrastructure. This is the best place to talk shop, ask questions, solicit feedback, and work together as a community to build totally sweet infrastructure.

📰 Newsletter

Sign up for our newsletter and join 3,000+ DevOps engineers, CTOs, and founders who get insider access to the latest DevOps trends, so you can always stay in the know. Dropped straight into your Inbox every week — and usually a 5-minute read.

📆 Office Hours

Join us every Wednesday via Zoom for your weekly dose of insider DevOps trends, AWS news and Terraform insights, all sourced from our SweetOps community, plus a live Q&A that you can’t find anywhere else. It's FREE for everyone!

About

This project is maintained by Cloud Posse, LLC.

We are a DevOps Accelerator for funded startups and enterprises. Use our ready-to-go terraform architecture blueprints for AWS to get up and running quickly. We build it with you. You own everything. Your team wins. Plus, we stick around until you succeed.

Your team can operate like a pro today.

Ensure that your team succeeds by using our proven process and turnkey blueprints. Plus, we stick around until you succeed.

📚 See What's Included

• Reference Architecture. You'll get everything you need from the ground up built using 100% infrastructure as code.
• Deployment Strategy. You'll have a battle-tested deployment strategy using GitHub Actions that's automated and repeatable.
• Site Reliability Engineering. You'll have total visibility into your apps and microservices.
• Security Baseline. You'll have built-in governance with accountability and audit logs for all changes.
• GitOps. You'll be able to operate your infrastructure via Pull Requests.
• Training. You'll receive hands-on training so your team can operate what we build.
• Questions. You'll have a direct line of communication between our teams via a Shared Slack channel.
• Troubleshooting. You'll get help to triage when things aren't working.
• Code Reviews. You'll receive constructive feedback on Pull Requests.
• Bug Fixes. We'll rapidly work with you to fix any bugs in our projects.

License

Preamble to the Apache License, Version 2.0

Complete license is available in the [`LICENSE`](LICENSE) file. ```text Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

https://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

</details>

## Trademarks

All other trademarks referenced herein are the property of their respective owners.
---
Copyright © 2017-2024 [Cloud Posse, LLC](https://cpco.io/copyright)


<a href="https://cloudposse.com/readme/footer/link?utm_source=github&utm_medium=readme&utm_campaign=cloudposse/geodesic&utm_content=readme_footer_link"><img alt="README footer" src="https://cloudposse.com/readme/footer/img"/></a>

<img alt="Beacon" width="0" src="https://ga-beacon.cloudposse.com/UA-76589703-4/cloudposse/geodesic?pixel&cs=github&cm=readme&an=geodesic"/>

geodesic's Issues

Fix `$HOME` Mounting for WSL

what

• Mounting $HOME to /localhost is not working on WSL (Windows Shell for Linux)

why

• Explain why this is a problem and what is the expected behavior.
• Explain why this feature request or enhancement is beneficial.

examples

This works:

docker run -it --rm -v /C/Users/sebas_000/AppData/Local/lxss/home/martaver:/test alpine sh

This does not:

docker run -it --rm -v /home/martaver:/test alpine sh

Maybe we should do something like in the wrapper script if we detect WSL:

mount --bind /mnt/c /c

or

mount --bind /C/Users/sebas_000/AppData/Local/lxss/home/martaver /home/martaver

references

• cloudposse-archives/root.cloudposse.co#8
• microsoft/WSL#1854
• https://superuser.com/questions/1344407/docker-on-wsl-wont-bind-mount-home
• https://nickjanetakis.com/blog/setting-up-docker-for-windows-and-wsl-to-work-flawlessly

Add Support for a Dotfile Manager

what

• Provide a standard interface for shell extensions
• Re-use some existing standard

why

• Allow users to define their own aliases, prompts, inputrcs, etc

references

• https://github.com/dotphiles/dotphiles
• https://github.com/TheLocehiliosan/yadm

Move Pip Installation to `requirements.txt`

what

• Move all python requirements to requirements.txt
• Use multi-stage build pattern as described here: https://blog.realkinetic.com/building-minimal-docker-containers-for-python-applications-37d0272c52f3

FROM python:3.6-alpine as base
FROM base as builder
RUN mkdir /install
WORKDIR /install
COPY requirements.txt /requirements.txt
RUN pip install --install-option="--prefix=/install" -r /requirements.txt
FROM base
COPY --from=builder /install /usr/local

why

• Rely on python package management
• Automatic package updates by Dependabot

Release 0.16.1 - broke geodesic shell

what

• Release https://github.com/cloudposse/geodesic/tree/0.16.1 broke shell

How to reproduce

• make build - Build geodesic module from geodesic:0.16.1
• make install - Install geodesic module
• $CLUSTER_NAME - run into shell

Expect

• Got shell command line

Exists

goruha@goruha-laptop ~/projects/cloudposse/example.com (feature-collect-logs●●)$ example.com                                                  [ruby-2.5.1p57]
# Mounting /home/goruha into container
# Starting new example.com session from r.cfcr.io/example.com:latest
# Exposing port 39257

• When I click Ctlr+D I got

goruha@goruha-laptop ~/projects/cloudposse/example.com (feature-collect-logs●●)$ example.com                                                  [ruby-2.5.1p57]
# Mounting /home/goruha into container
# Starting new example.com session from r.cfcr.io/example.com:latest
# Exposing port 39257
^C04da1f47d29c:~#

Add pwgen

what

• add pwgen

why

• Useful for generating dynamic passwords

Add Support for `kiam` to Master Helmfile

what

• https://github.com/uswitch/kiam

why

• Numerous stability issues with kube2iam
• Kiam adds caching support, better security, better overall architecture
• Highly maintained

Linux support (including new-user documentation)

This isn't a bug-report per-se but a new-user feedback list and items that would be needed to complete the documentation:

• README needs installation section.
• Install script needs to detect and use unix line-endings where appropriate
• aws-vault needs to be fully functional prior to installation
• New project setup guidance would be helpful

• I'm still struggling with how to use geodesic with an existing infrastructure. For instance, I have a full terraform project. How would I start using geodesic with that project? I'm sure you mount it somehow when you start geodesic, but I don't really see that option.
• The cloudeposse/geodesic output script (which you pipe into bash to install, which isn't documented) is in windows line-endings. I had to execute docker run --rm -it $IMAGE | tr -d "\r" > $TMP && bash $TMP 0.9.17
• aws-vault linux support is half-baked. I'm still struggling to get it fully working. It seems doing a backend=file helps, but there's still some weirdness I'm trying to understand
• Why does geodesic need to run with --privileged? If it's a must, then this complicates using aws-vault in both geodesic and native (geodesic will create vault keys as root in your home directory)

support for zsh

what

• Do not require bash4
• Would be great if we can support zsh as well.

why

• The default script requires bash4 which enforce to have separate bash installation (e.g. via brew)

[kops] Enabled Encrypted EBS Volumes

what

 - etcdMembers:
    {{- range (getenv "KOPS_AVAILABILITY_ZONES" | strings.Split ",") }}
    - encryptedVolume: true
 ...
    {{- end }}

Upgrade Helm

what

• Use helm from `packages

references

• cloudposse/packages#12

[kops] Add Support for Extensions

what

# Allow the manifest to be extended via a datasource
{{if (datasourceExists "extensions")}}
{{include "extensions"}}
{{end}}

why

• Allow users to extend the manifest

use-case

Add custom instance pools.

e.g.

---
apiVersion: kops/v1alpha2
kind: InstanceGroup
metadata:
  labels:
    kops.k8s.io/cluster: {{getenv "KOPS_CLUSTER_NAME"}}
  name: example-nodes
spec:
  detailedInstanceMonitoring: {{ getenv "KOPS_CLOUDWATCH_DETAILED_MONITORING" "true" }}
  {{- if getenv "NODE_IG_SG_IDS" }}
  additionalSecurityGroups:
    {{- range (getenv "NODE_IG_SG_IDS" | strings.Split ",") }}
  - {{.}}
    {{- end }}
  {{- end}}
  associatePublicIp: false
  cloudLabels:
    Role: k8s-vortex-node
  image: {{ getenv "KOPS_BASE_IMAGE" }}
  machineType: {{getenv "EXAMPLE_MACHINE_TYPE"}}
  maxSize: {{getenv "EXAMPLE_MAX_SIZE"}}
  minSize: {{getenv "EXAMPLE_MIN_SIZE"}}
  nodeLabels:
    dedicated: {{getenv "EXAMPLE_LABEL" | default "example" }}
  role: Node
  subnets:
  - {{getenv "AWS_REGION"}}a
  taints:
  - dedicated={{getenv "EXAMPLE_LABEL" | default "example" }}:NoSchedule

Syslog Started in Each Login Shell

what

• Every time bash -l is run (e.g. by multiple concurrent sessions in the same container), then a new syslog-ng daemon is spawned

PID   USER     TIME  COMMAND
    1 root      0:00 /bin/bash -l
    7 root      0:00 aws-vault server
   28 root      0:00 ssh-agent
   31 root      0:00 {syslog-ng} supervising syslog-ng
   32 root      0:00 syslog-ng -f /etc/syslog-ng/syslog-ng.conf
   37 root      0:00 aws-vault exec --assume-role-ttl=1h --server cpco-testing-admin -- bash -l
   46 root      0:00 bash -l
   65 root      0:00 {syslog-ng} supervising syslog-ng
   66 root      0:00 syslog-ng -f /etc/syslog-ng/syslog-ng.conf
  796 root      0:01 kops rolling-update cluster --yes
  812 root      0:00 bash -l
  839 root      0:00 {syslog-ng} supervising syslog-ng
  840 root      0:00 syslog-ng -f /etc/syslog-ng/syslog-ng.conf
  870 root      0:00 ps uxaww

why

• /etc/profile.d/syslog-ng.sh doesn't check for already running instance

Add helm-push plugin

what

• Add helm-push plugin (e.g. helm plugin install https://github.com/chartmuseum/helm-push)

why

• Support codefresh chartmuseum repo which uses custom auth scheme

references

• https://codefresh.io/docs/docs/new-helm/managed-helm-repository/

Cloud Config Unmount Broken

what

• Running cloud config unmount fails

Add Better Support for Minikube

what

• Add support for Docker for Mac (DFM) Kubernetes or Minikube

why

• Faster LDE, protyping
• Testing Helm Charts, Helmfiles

howto

I got it working very easily.

Here's what I did (manually):

1. Enable Kubnernetes mode in DFM.

2. Disable the DOCKER_DNS stuff that points to 8.8.8.8 in the wrapper script as it breaks DFM DNS resolution of docker.for.mac.localhost
3. Update /localhost/.kube/config to use FQHN for Docker host docker.for.mac.localhost
4. export KUBECONFIG=/localhost/.kube/config

sed -i 's,https://localhost:6443,https://docker.for.mac.localhost:6443,g' /localhost/.kube/config

I'd like us to simplify this process so it basically works out-of-the-box.

Fix Typo

what

• reating should be reading

why

• Misspelled

references

• https://github.com/cloudposse/geodesic/blob/master/Dockerfile#L45

Add Shell Linting

what

• Use shellcheck to lint all bash scripts
• Consider adding target to build-harness

why

• Reduce bugs, improve consistency

AWS Configure Does Not Respect ENVs

what

• aws configure does not respect AWS_DATA_PATH or AWS_CONFIG_FILE

why

• When running aws configure it always writes to ~/.aws regardless of the official ENVs.

s3fs should not remount filesystem if already mounted

what

mount -a should not produce error

why

s3fs script should check if filesystem is already mounted

Deprecate Packer

what

• Remove packer from this image

why

• It's not used by any of our projects
• We should provide it as part of cloudposse/packages for optional inclusion

references

• cloudposse/packages#47

Move All Helmfile Values Inline

what

• Use inline values

why

• More concise format
• Does not require external file
• Does not require YAML-selectors

example

geodesic/rootfs/conf/kops/helmfile.yaml

Lines 445 to 481 in b6e46f4

	- rbac:
	create: {{ env "KIAM_RBAC_CREATE" | default "false" }}
	agent:
	gatewayTimeoutCreation: "5s"
	host:
	interface: "cali+"
	nodeSelector:
	kubernetes.io/role: "node"
	tolerations:
	- operator: "Exists"
	tlsFiles:
	### Required: KIAM_AGENT_TLS_CA; e.g. base64-encoded ca.pem
	ca: '{{ env "KIAM_AGENT_TLS_CA" }}'
	### Required: KIAM_AGENT_TLS_CERT; e.g. base64-encoded agent.pem
	cert: '{{ env "KIAM_AGENT_TLS_CERT" }}'
	### Required: KIAM_AGENT_TLS_KEY; e.g. base64-encoded agent-key.pem
	key: '{{ env "KIAM_AGENT_TLS_KEY" }}'
	server:
	gatewayTimeoutCreation: "5s"
	nodeSelector:
	kubernetes.io/role: "master"
	tolerations:
	- key: "node-role.kubernetes.io/master"
	effect: "NoSchedule"
	operator: "Exists"
	extraHostPathMounts:
	- name: "ssl-certs"
	mountPath: "/etc/ssl/certs"
	hostPath: '{{ env "KIAM_HOST_CERT_PATH" | default "/etc/ssl/certs" }}'
	readOnly: true
	tlsFiles:
	### Required: KIAM_AGENT_TLS_CA; e.g. base64-encoded ca.pem
	ca: '{{ env "KIAM_SERVER_TLS_CA" }}'
	### Required: KIAM_SERVER_TLS_CERT; e.g. base64-encoded server.pem
	cert: '{{ env "KIAM_SERVER_TLS_CERT" }}'
	### Required: KIAM_SERVER_TLS_KEY; e.g. base64-encoded server-key.pem
	key: '{{ env "KIAM_SERVER_TLS_KEY" }}'

Demo Video Needs to be Updated

I was hoping to watch your demo but after 2 minutes of waiting and staring at rotating backslash I gave up.
Why don't you use asciinema for this kind of thing. It can cut long pauses or provides a slide to skip certain parts of a video.

Init AWS Config Script

what

• Add script to easily bootstrap .aws/config from run-time environment settings
• IAM username should be prompted for
• Should define some canonical ENVs and refactor our stanard TF_VAR_* envs to use these

why

• Make it easier for first-time users to get up and running quickly

example

#!/usr/bin/env bash

AWS_SOURCE_PROFILE="cpco"
AWS_PROFILE="cpco-root-admin"
AWS_REGION="us-west-2"
AWS_IAM_ROLE_ARN="arn:aws:iam::847230548837:role/${AWS_PROFILE}"
AWS_IAM_MFA_SERIAL="arn:aws:iam::847230548837:mfa/[email protected]"

function configure() {
  # When creating a new/non-existent profile, the `aws configure` command gets confused if `AWS_PROFILE` or `AWS_DEFAULT_PROFILE`
  # are set to something which does not yet exist. Running it in `env` lets us sanify the environment.

  echo "[$AWS_PROFILE] $1=$2"
  env -u AWS_PROFILE -u AWS_DEFAULT_PROFILE aws configure set "profile.${AWS_PROFILE}.$1" "$2"
}

configure "region" "$AWS_REGION"
configure "role_arn" "$AWS_IAM_ROLE_ARN"
configure "mfa_serial" "$AWS_IAM_MFA_SERIAL"
configure "source_profile" "$AWS_SOURCE_PROFILE"

maybe we should also call this command if source profile not yet defined:

aws-vault add ${AWS_SOURCE_PROFILE}

pidof errors

what

pidof: unrecognized option: x
BusyBox v1.28.4 (2018-05-30 10:45:57 UTC) multi-call binary.

Usage: pidof [OPTIONS] [NAME]...

List PIDs of all processes with names that match NAMEs

	-s	Show only one PID
	-o PID	Omit given pid
		Use %PPID to omit pid of pidof's parent

why

• pidof on busybox/musl supports different arguments

[kops] Add Support for aws-iam-authenticator

what

• Add support for the IAM authenticator for kubernetes

why

• RBAC for users

references

• https://github.com/kubernetes-sigs/aws-iam-authenticator

depends on

• cloudposse/packages#64

ssh-agent is down

What

• On start got error that ssh agent is down

Steps to reproduce

• Run geodesic

Expect

• No error

Got

# Mounting /home/goruha into container
# Attaching to existing geodesic session
Available commands:
  leave-role      Leave the current role; run this to release your session
  assume-role     Assume a new role; run this to renew your session
  setup-role      Setup a new role; run this to configure your AWS profile
  use-profile     Use a preconfigured profile; run this to use an AWS profile without assumed roles

Error connecting to agent: Connection refused
Error connecting to agent: Connection refused
Makefile:145: recipe for target 'add-ssh-key' failed
make: *** [add-ssh-key] Error 2

Add Support for Automatic Env File

what

• Look for a ~/.geodesic/env file and pass it as --env-file, if found

why

• Provide a way to set some defaults for all geodesic shells.

[kops] Add Support for Enhanced Monitoring

what

detailedInstanceMonitoring: {{ getenv "KOPS_CLOUDWATCH_DETAILED_MONITORING" "true" }}

why

• More detailed monitoring

Install chartmuseum without tls

what

• helmfile.yaml sets ingress.tls[0].secretName and ingress.tls[0].hosts[0] for the chartmuseum releases
• Make these values optional

why

• Allow chartmuseum charts to be installed without tls

Add helm-s3 plugin

what

• Install the helm-s3 plugin

why

• Avoid the need to manage chart repository

references

• https://github.com/hypnoglow/helm-s3

Add Support for New Portal

what

• Update helmfile.yaml to support cloudposse/charts#149

why

• New portal uses different values

Make sure Dockerfile from create-cluster.sh matches root.cloudposse.co

If you start a new project following the Quick Start guide, would the expectation be that the example.foo.bar website matches root.cloudposse.co Dockerfile?

Add Support for Custom Prompts

what

• Add support for PROMPT_STYLE environment variable that alters the behavior of the shell prompt

why

• The current utf8 heavy prompt breaks some terminals
• Users have mentioned they'd prefer a plain prompt

Relocate Helmfiles to Dedicated Repository

what

• Move helmfiles to https://github.com/cloudposse/helmfiles

why

• Allow helmfiles to be versioned independently

references

• cloudposse/helmfiles#2

Shell Formatting

what

• Use shfmt to format all shell scripts
• Consider adding target to build-harness

why

• Improve consistency

Use TLS for APK repositories

what

• Use TLS for apk repositories
• Use the sed hack to use fastly upstream CDN

why

• More secure
• Mitigate MITM attacks

references

• gliderlabs/docker-alpine#184

Deprecate Helmfile.yaml and `kiam` scripts

what

• Deprecate the helmfile.yaml

why

• Moved to https://github.com/cloudposse/helmfiles

aws completion broken in 0.9.18

 ⧉  geodesic
❌   (none) ~ ➤  l /etc/bash_completion.d/
total 372
lrwxrwxrwx 1 root root     37 Jun  7 18:18 aws.sh -> /usr/local/aws/bin/aws_bash_completer

but it is now at:

❌   (none) ~ ➤  which aws_bash_completer 
/usr/bin/aws_bash_completer

Upgrade Syslog-ng Configuration

what

• Fix this warning

[2018-08-01T23:13:04.271134] WARNING: Configuration file format is too old, syslog-ng is running in compatibility mode. Please update it to use the syslog-ng 3.13 format at your time of convenience. To upgrade the configuration, please review the warnings about incompatible changes printed by syslog-ng, and once completed change the @version header at the top of the configuration file.;

why

We recently upgraded to alpine:3.8 which bumped the syslog-ng version.

Add Support for Windows (WSL/Ubuntu Linux)

what

• Add support for running Geodesic shells on Windows using WSL

why

• We have some early adopters running windows
• Minimal effort seems required to get this working on windows (seems very close!)

references

• cloudposse-archives/root.cloudposse.co#6
• #199

AWS Configuration does not exist

My environment:

OS:

sw_vers
ProductName:	Mac OS X
ProductVersion:	10.12.6
BuildVersion:	16G29

ls -lah ~/.aws/
total 16
drwxr-xr-x   5 sweetops  staff   170B Sep 12 22:50 .
drwxr-xr-x+ 77 sweetops  staff   2.6K Sep 20 14:09 ..
drwxr-xr-x   3 sweetops  staff   102B Sep 12 22:50 cli
-rw-------   1 sweetops  staff   444B Sep 13 18:58 config
-rw-------   1 sweetops  staff   341B Sep 13 19:30 credentials

Steps for reproduce:

docker run --rm -it test.com > ./geodesic
chmod 755 geodesic
./geodesic use --name=test.com --dev

Enable Optional RBAC in Kops Manifest

what

• Add env flag to enable/disable RBAC (default to off, for backwards compatibility)

why

• RBAC is the new norm (for almost a year now)
• We need to start supporting it

/usr/local/bin/s3 still references s3fs and not goofys

When I run this (in geodesic or the Dockerfile)

s3 fstab TF_BUCKET /dev /secrets/tf/

The fstab contains:

s3fs#TF_BUCKET:/dev /secrets/tf/ fuse _netdev,allow_other,rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions 0 0

Add bats-core

what

• Add bats-core

why

• Automated tests

Define Resource Limits for Kiam

what

• Set memory and CPU limits for Kiam

why

• Kiam may have a memory leak

references

• uswitch/kiam#72
• uswitch/kiam#125

Add Stern for Multi-pod tailing

what

• https://github.com/wercker/stern

why

• Facilitate debuging/developing workflows

Decompose `helmfile.yaml` to `helmfile.d`

what

• https://github.com/cloudposse/geodesic/blob/master/rootfs/conf/kops/helmfile.yaml

why

• More maintainable

related

• roboll/helmfile#160

• roboll/helmfile#137

• roboll/helmfile#151

• Update documentation for for helmfile.d

Historical command line editing is broken

what

Concerning version 0.12.6. Also reproduced in 0.11.0.

Editing historical command lines using emacs keys is broken in certain circumstances. My guess is that it has to do with a divergence between the actual length of the prompt when output versus the length of the prompt when queried by the command line editor.

Reproducing this bug is a little tricky. This seems to work for me, but you might have to try some variations.

1. Enter a long command at the command line:

   echo top level this is a long command
   

2. Press the up-arrow ↑ to recall the command to the command line.
3. Press ctrl-A to move the cursor to the beginning of the command line.

Expected: cursor hovers over "e" in echo.
Observed: cursor hovers over "c" in echo.

why

Not only does this cause difficulty in editing historical command lines, it results in a dangerous situation where the command visible on the command line is not exactly what will be submitted when you hit return.

[kops] Add Support for Cluster Autoscaler

what

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "autoscaling:DescribeAutoScalingGroups",
                "autoscaling:DescribeAutoScalingInstances",
                "autoscaling:DescribeTags",
                "autoscaling:SetDesiredCapacity",
                "autoscaling:TerminateInstanceInAutoScalingGroup"
            ],
            "Resource": "*"
        }
    ]
}

why

• To support scaling cluster for GPU Instances

references

• https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md
• https://github.com/kubernetes/kops/tree/f400a882d7c274a77d95050452d263d0faf42005/addons/cluster-autoscaler

Fix Shell Concurrency

what

• aws-vault: error: Server failed: exit status 2

why

• aws-vault server should only be run once globally across all shell because it binds to 169.254.169.254

references

• cloudposse-archives/root.cloudposse.co#8 (comment)