basicauth-transport

A simple transport to wrap other transport to add basic auth to request.

Usage

package main

import (
    "github.com/ArthurHlt/basicauth-transport"
    "net/http"
)

func main() {

    http.DefaultClient.Transport = transport.NewDefaultBasicAuthTransport("username", "password")

    // with  a custom transport
    http.DefaultClient.Transport = transport.NewBasicAuthTransport(
        "username", 
        "password",
        &http.Transport{})
}

Not Found

cf-chocolatey

A chocolatey package to install official command line client for Cloud Foundry.

Installation

1. Install chocolatey (follow instructions chocolatey: https://chocolatey.org/
2. Run in your prefered cli $ choco install cf
3. You've done.

Rebuild

To maintain always up-to-date this choco package with https://github.com/cloudfoundry/cli I've made a php script which can be run everyday.

To try it run with php in cli command $ php rebuild.php.

It will:

1. Check if version between this github and the https://github.com/cloudfoundry/cli are the same
2. Recreate tools\chocolateyinstall.ps1 and cf.nuspec with this new version.
3. Repack the nugget package with the cpack command.
4. Push to https://chocolatey.org this new package.

CIWatch

This is a useful tool to see all status from your ci tools in a wink (tools like travis, scrutinizer, SensioLabsInsight or CodeClimate).

It provides also tools to directly create CI environment in one time and permit you to restart inspection on a repo.

[](Logo CIWatch)

What is deaph

Deaph is a deployer very flexible which you can use to deploy what you want through FTP, SFTP, Dropbox, Zip, Local or Amazon S3 After deploying your files you can use step as the same way as puppet or chief.

Installation

Deaph is .phar file you can download it.

How to use

dialog-watson-client

Client for dialogs watson module

Requirements

• Python 2.7
• Pip

Installation

Install with pip: pip install dialog-watson-client

Run the playground

Simply run in command line: dialog-watson-client --name=dialog-name path/to/dialog/file [--clean](optional: clean your dialogs in watson) and you will chat with your robot

At the first launch it will create a config file located to ~/.config-dialog-watson.yml and ask you your watson credentials

Usage for developers

Bootstrap example:

from dialog_watson_client.Client import Client
watsonClient = Client('user_watson', 'password_watson', 'file/path/to/dialog', 'your_dialog_name') # this library abstract the registering of dialog (and the update when you cahnge it) and run it, to do that it will store your dialog id in a file called `dialog_id_file.txt`
watsonClient.start_dialog() # this will create the dialog into watson or update it and run the initialization of the conversation

resp = watsonClient.converse('hi') # talk to the robot, here it will say 'hi' and watson will answered
print resp.response # show the response from watson
watsonClient.get_profile().get_data() # get extracted data from watson in format: [key => value]

Note: If your file is in xml (and you have lxml lib installed) it will also check your format with xsd: https://www.ibm.com/smarterplanet/us/en/ibmwatson/developercloud/doc/dialog/download/WatsonDialogDocument_1.0.xsd

dockerfiles

Repo of dockerfiles

echo-colors

Echo in CLI with colors easily by using colorstring.

Installation

On *nix system

You can install this via the command-line with either curl or wget.

via curl

$ sh -c "$(curl -fsSL https://raw.github.com/ArthurHlt/echo-colors/master/bin/install.sh)"

via wget

$ sh -c "$(wget https://raw.github.com/ArthurHlt/echo-colors/master/bin/install.sh -O -)"

On windows

You can install it by downloading the .exe corresponding to your cpu from releases page: https://github.com/ArthurHlt/echo-colors/releases . Alternatively, if you have terminal interpreting shell you can also use command line script above, it will download file in your current working dir.

From go command line

Simply run in terminal:

$ go get github.com/ArthurHlt/echo-colors

Usage

NAME:
   echoc - Echo in colors some text easily

USAGE:
   echoc "[red] this is red [yellow]and yellow [_red_]with red background [bold] and bold [reset] and no colors"

VERSION:
   1.0.0

COMMANDS:
GLOBAL OPTIONS:
   -n           Optional. Do not print the trailing newline character
   --help, -h       show help
   --version, -v    print the version

ep_cloudfoundry

Not Found

Not Found

IocArt

IocArt is an another IOC (inversion of Control) and he is close too Spring Ioc style. The main point is that IocArt have his context file in yml. Bean is "class" wich you can inject inside their properties:

• Another bean
• Property file
• A yaml file read by yamlarh
• A stream

You can also import other yaml context in a yaml context

Installation

Through Composer, obviously:

{
    "require": {
        "arhframe/iocart": "1.*"
    }
}

Usage

use Arhframe\IocArt\BeanLoader;

$beanLoader = BeanLoader::getInstance();
$beanLoader->loadContext('your/yaml/file/for/context');

Examples

util

Util libraries for arhframe

Yamlarh

Yml injector for arhframe in standalone. You can inject into your yaml:

• object
• constant from scope
• Variable from global scope
• Variable from yaml file

You can also import other yaml inside a yaml file for overriding

Installation

Through Composer, obviously:

{
    "require": {
        "arhframe/yamlarh": "1.*"
    }
}

Usage

use Arhframe\Yamlarh\Yamlarh;

$yamlarh = new Yamlarh(__DIR__.'/path/to/yaml/file');
$array = $yamlarh->parse();

Exemple

Variable injection

Variable injection is hierarchical, it will find in this order:

1. In the yaml file with import
2. In your global scope
3. In you constant

Yaml file:

arhframe:
  myvar1: test
  myvar2: %arhframe.myvar1%
  myvar3: %var3%
  myvar4: %VARCONSTANT%

Php file:

use Arhframe\Yamlarh\Yamlarh;
$var3 = 'testvar';
define('VARCONSTANT', 'testconstant');
$yamlarh = new Yamlarh(__DIR__.'/test.yml');
$array = $yamlarh->parse();
echo print_r($array);

Output:

  Array
  (
      [arhframe] => Array
          (
              [myvar1] => test
              [myvar2] => test
              [myvar3] => testvar
              [myvar4] => testconstant
          )

  ) 

Object injection

It use snakeyml (yaml parser for java) style:

arhframe:
  file: !! Arhframe.Util.File(test.php) #will instanciate this: Arhframe\Util\File('test.php') in file var after parsing

Import

Import are also hierarchical the last one imported will override the others. Use @import in your file:

file1.yml

arhframe:
  var1: var
test: arhframe

@import:
 - file2.yml #you can use a relative path to your yaml file or an absolute

file2.yml

arhframe:
  var1: varoverride
test2: var3

After parsing file1.yml, yml will look like:

arhframe:
  var1: varoverride
test: arhframe
test2: var3

Include

You can include a yaml file into another:

file1.yml

arhframe:
  var1: var
test:
  @include:
    - file2.yml #you can use a relative path to your yaml file or an absolute

file2.yml

test2: var3

After parsing file1.yml, yml will look like:

arhframe:
  var1: var
test:
  test2: var3

bosh CLI

• Documentation: bosh.io/docs/cli-v2
• Slack: #bosh on https://slack.cloudfoundry.org
• Mailing list: cf-bosh
• CI: https://main.bosh-ci.cf-app.com/teams/main/pipelines/bosh:cli
• Roadmap: Pivotal Tracker

Usage

• Install

Client Library

This project includes director and uaa packages meant to be used in your project for programmatic access to the Director API.

See docs/example.go for a live short usage example.

Developer Notes

• Workstation setup docs
• Test docs
• CLI workflow
  • Architecture docs

BOSH Prometheus Exporter

A Prometheus exporter for BOSH metrics. Please refer to the FAQ for general questions about this exporter.

Architecture overview

Installation

Binaries

Download the already existing binaries for your platform:

$ ./bosh_exporter <flags>

From source

Using the standard go install (you must have Go already installed in your local machine):

$ go install github.com/bosh-prometheus/bosh_exporter
$ bosh_exporter <flags>

Docker

To run the bosh exporter as a Docker container, run:

$ docker run -p 9190:9190 boshprometheus/bosh-exporter <flags>

Cloud Foundry

The exporter can be deployed to an already existing Cloud Foundry environment:

$ git clone https://github.com/bosh-prometheus/bosh_exporter.git
$ cd bosh_exporter

Modify the included application manifest file to include your BOSH properties. Then you can push the exporter to your Cloud Foundry environment:

$ cf push

BOSH

This exporter can be deployed using the Prometheus BOSH Release.

Usage

Flags

[1] When BOSH delegates user managament to UAA, either bosh.username and bosh.password or bosh.uaa.client-id and bosh.uaa.client-secret flags may be used; otherwise bosh.username and bosh.password will be required. When using UAA and the bosh.username and bosh.password authentication method, tokens are not refreshed, so after a period of time the exporter will be unable to communicate with the BOSH API, so use this method only when testing the exporter. For production, it is recommended to use the bosh.uaa.client-id and bosh.uaa.client-secret authentication method.

Metrics

The exporter returns the following metrics:

The exporter returns the following Deployments metrics:

The exporter returns the following Jobs metrics:

The exporter returns the following ServiceDiscovery metrics:

Service Discovery

If the ServiceDiscovery collector is enabled, the exporter will write a json file at the sd.filename location containing a list of static configs that can be used with the Prometheus file-based service discovery mechanism:

[
  {
    "targets": ["10.244.0.12"],
    "labels":
      {
        "__meta_bosh_job_process_name": "bosh_exporter"
      }
  },
  {
    "targets": ["10.244.0.11", "10.244.0.12", "10.244.0.13", "10.244.0.14"],
    "labels":
      {
        "__meta_bosh_job_process_name": "node_exporter"
      }
  }
]

The list of targets can be filtered using the sd.processes_regexp flag.

Contributing

Refer to the contributing guidelines.

License

Apache License 2.0, see LICENSE.

Not Found

Cloud Foundry Java Client

The cf-java-client project is a Java language binding for interacting with a Cloud Foundry instance. The project is broken up into a number of components which expose different levels of abstraction depending on need.

• cloudfoundry-client – Interfaces, request, and response objects mapping to the Cloud Foundry REST APIs. This project has no implementation and therefore cannot connect a Cloud Foundry instance on its own.
• cloudfoundry-client-spring – The default implementation of the cloudfoundry-client project. This implementation is based on the Spring Framework RestTemplate.
• cloudfoundry-operations – An API and implementation that corresponds to the Cloud Foundry CLI operations. This project builds on the cloudfoundry-cli and therefore has a single implementation.
• cloudfoundry-maven-plugin / cloudfoundry-gradle-plugin – Build plugins for Maven and Gradle. These projects build on cloudfoundry-operations and therefore have single implementations.

Most projects will need two dependencies; the Operations API and an implementation of the Client API. For Maven, the dependencies would be defined like this:

<dependencies>
    <dependency>
        <groupId>org.cloudfoundry</groupId>
        <artifactId>cloudfoundry-client-spring</artifactId>
        <version>${cf-java-client.version}</version>
    </dependency>
    <dependency>
        <groupId>org.cloudfoundry</groupId>
        <artifactId>cloudfoundry-operations</artifactId>
        <version>${cf-java-client.version}</version>
    </dependency>
    ...
</dependencies>

The artifacts can be found in the Spring release and snapshot repositories:

<repositories>
    <repository>
        <id>spring-releases</id>
        <name>Spring Releases</name>
        <url>http://repo.spring.io/release</url>
    </repository>
    ...
</repositories>

<repositories>
    <repository>
        <id>spring-snapshots</id>
        <name>Spring Snapshots</name>
        <url>http://repo.spring.io/snapshot</url>
        <snapshots>
            <enabled>true</enabled>
        </snapshots>
    </repository>
    ...
</repositories>

For Gradle, the dependencies would be defined like this:

dependencies {
    compile "org.cloudfoundry:cloudfoundry-client-spring:$cfJavaClientVersion"
    compile "org.cloudfoundry:cloudfoundry-operations:$cfJavaClientVersion"
    ...
}

The artifacts can be found in the Spring release and snapshot repositories:

repositories {
    maven { url "http://repo.spring.io/release" }
    ...
}

repositories {
    maven { url "http://repo.spring.io/snapshot" }
    ...
}

Usage

Both the cloudfoundry-operations and cloudfoundry-client projects follow a "Reactive" design pattern and expose their responses with Reactive Streams Publishers. The choice to expose Reactive Streams Publishers gives the project interoperability with the various reactive framework implementations such as Project Reactor and RxJava. In the examples that follow, Project Reactor is used, but all reactive frameworks work similarly.

CloudFoundryClient and CloudFoundryOperations Builders

The lowest-level building block of the API is a CloudFoundryClient. This is only an interface and the default implementation of this is the SpringCloudFoundryClient. To instantiate one, you configure it with a builder:

SpringCloudFoundryClient.builder()
    .host("api.run.pivotal.io")
    .username("example-username")
    .password("example-password")
    .build();

In Spring-based applications, you'll want to encapsulate this in a bean definition:

@Bean
CloudFoundryClient cloudFoundryClient(@Value("${cf.host}") String host,
                                      @Value("${cf.username}") String username,
                                      @Value("${cf.password}") String password) {
    return SpringCloudFoundryClient.builder()
            .host(host)
            .username(username)
            .password(password)
            .build();
}

The CloudFoundryClient provides direct access to the raw REST APIs. This level of abstraction provides the most detailed and powerful access to the Cloud Foundry instance, but also requires users to perform quite a lot of orchestration on their own. Most users will instead want to work at the CloudFoundryOperations layer. Once again this is only an interface and the default implementation of this is the DefaultCloudFoundryOperations. To instantiate one, you configure it with a builder:

new CloudFoundryOperationsBuilder()
    .cloudFoundryClient(cloudFoundryClient)
    .target("example-organization", "example-space")
    .build();

In Spring-based applications, you'll want to encapsulate this in a bean definition as well:

@Bean
CloudFoundryOperations cloudFoundryOperations(CloudFoundryClient cloudFoundryClient,
                                              @Value("${cf.organization}") String organization,
                                              @Value("${cf.space}") String space) {
    return new CloudFoundryOperationsBuilder()
            .cloudFoundryClient(cloudFoundryClient)
            .target(organization, space)
            .build();
}

CloudFoundryOperations APIs

Once you've got a reference to the CloudFoundryOperations, it's time to start making calls to the Cloud Foundry instance. One of the simplest possible operations is list all of the organizations the user is a member of. The following example does three things:

1. Requests a list of all organizations
2. Extracts the name of each organization
3. Prints the name of the each organization to System.out

Streams
    .wrap(this.cloudFoundryOperations.organizations().list())
    .map(Organization::getName)
    .consume(System.out::println);

To relate the example to the description above the following happens:

1. Streams.wrap(...) – Wraps the Reactive Streams Publisher (an interoperability type) in the Reactor-native Stream type
2. .map(...) – Maps an input type to an output type. This example uses a method a reference and the equivalent lambda would look like organization -> organization.getName().
3. consume... – The terminal operation that consumes each item in the stream. Again, this example uses a method reference and the the equivalent lambda would look like name -> System.out.println(name).

CloudFoundryClient APIs

As mentioned earlier, the cloudfoundry-operations implementation builds upon the cloudfoundry-client API. That implementation takes advantage of the same reactive style in the lower-level API. The implementation of the Organizations.list() method (which was demonstrated above) looks like the following (roughly):

ListOrganizationsRequest request = ListOrganizationsRequest.builder()
    .page(1)
    .build();

Streams
    .wrap(cloudFoundryClient.organizations().list(request))
    .flatMap(response -> Streams.from(response.getResources))
    .map(resource -> {
        return Organization.builder()
            .id(resource.getMetadata().getId())
            .name(resource.getEntity().getName())
            .build();
    });

The above example is more complicated:

1. Streams.wrap(...) – Wraps the Reactive Streams Publisher in the Reactor-native Stream type
2. .flatMap(...) – substitutes the original stream with a stream of the Resources returned by the requested page
3. .map(...) – Maps the Resource to an Organization type

Maven Plugin

TODO: Document once implemented

Gradle Plugin

TODO: Document once implemented

Development

The project depends on Java 8 but is built to be Java 7 compatible. To build from source and install to your local Maven cache, run the following:

$ ./mvnw clean install

To run the the integration tests, run the following:

$ ./mvnw -Pintegration-test clean test

IMPORTANT Integration tests should be run against an empty Cloud Foundry instance. The integration tests are destructive, nearly everything on an instance given the chance.

The integration tests require a running instance of Cloud Foundry to test against. We recommend using MicroPCF to start a local instance to test with. To configure the integration tests with the appropriate connection information use the following environment variables:

Contributing

Pull requests and Issues are welcome.

License

This project is released under version 2.0 of the Apache License.

cf-ssh

SSH into a running container for your Cloud Foundry application, run one-off tasks, debug your app, and more.

Initial implementation requires the application to have a manifest.yml.

Also, cf-ssh requires that you run the command from within the project source folder. It performs a cf push to create a new application based on the same source code/path, buildpack, and variables. Once CF Runtime supports copy app bits #78847148, then cf-ssh will be upgraded to use app bit copying, and not require local access to project app bits.

It is desired that cf-ssh works correctly from all platforms that support the cf CLI.

Windows is a target platform but has not yet been tested. Please give feedback in the Issues.

Requirements

This tool requires the following CLIs to be installed

• cf (download)
• ssh (pre-installed on all *nix; download for Windows)

It is assumed that in using cf-ssh you have already successfully targeted a Cloud Foundry API, and have pushed an application (successfully or not).

This tool also currently requires outbound internet access to the http://tmate.io/ proxies. In future, to avoid the requirement of public Internet access, it would be great to package up the tmate server as a BOSH release and deploy it into the same infrastructure as the Cloud Foundry deployment.

Why require ssh CLI?

This project is written in the Go programming language, and there is a candidate library go.crypto that could have natively supported an interactive SSH session. Unfortunately, the SSL supports a subset of ciphers that don't seem to work with tmate.io proxies [stackoverflow]

Using the go.crypto library I was getting the following error. In future, perhaps either tmate.io or go.crypto will change to support each other.

unable to connect: ssh: handshake failed: ssh: no common algorithms

Installation

Download a pre-compiled release for your platform. Place it in your $PATH or %PATH% and rename to cf-ssh (or cf-ssh.exe for Windows).

Alternately, if you have Go setup you can build it from source:

go get github.com/cloudfoundry-community/cf-ssh

Usage

cd path/to/app
cf-ssh -f manifest.yml

Publish releases

To generate the pre-compiled executables for the target platforms, using gox:

gox -output "out/{{.Dir}}_{{.OS}}_{{.Arch}}" -osarch "darwin/amd64 linux/amd64 windows/amd64 windows/386" ./...

They are now in the out folder:

-rwxr-xr-x  1 drnic  staff   4.0M Oct 25 23:05 cf-ssh_darwin_amd64
-rwxr-xr-x  1 drnic  staff   4.0M Oct 25 23:05 cf-ssh_linux_amd64
-rwxr-xr-x  1 drnic  staff   3.4M Oct 25 23:05 cf-ssh_windows_386.exe
-rwxr-xr-x  1 drnic  staff   4.2M Oct 25 23:05 cf-ssh_windows_amd64.exe

VERSION=v0.1.0
github-release release -u cloudfoundry-community -r cf-ssh -t $VERSION --name "cf-ssh $VERSION" --description 'SSH into a running container for your Cloud Foundry application, run one-off tasks, debug your app, and more.'

for arch in darwin_amd64 linux_amd64 windows_amd64 windows_386; do
  github-release upload -u cloudfoundry-community -r cf-ssh -t $VERSION --name cf-ssh_$arch --file out/cf-ssh_$arch*
done

UAA Auth Route Service

(Based on https://github.com/benlaplanche/cf-basic-auth-route-service)

Using the new route services functionality available in Cloud Foundry, you can now bind applications to routing services. Traffic sent to your application is routed through the bound routing service before continuing onto your service.

This allows you to perform actions on the HTTP traffic, such as enforcing authentication, rate limiting or logging.

For more details see:

• Route Services Documentation

Getting Started

There are two components and thus steps to getting this up and running. The broker and the filtering proxy.

Before getting started you will need:

• Access to a cloud foundry deployment
• UAA client credentials

Uncomment and fill in the environment variables required as the sample in broker-manifest.yml.sample and copy the manifest to broker-manifest.yml.

Run cf push -f broker-manifest.yml to deploy the uaa-guard-proxy app.

Uncomment and fill in the environment variables required as the sample in proxy-manifest.yml.sample and copy the manifest to proxy-manifest.yml.

Run cf push -f proxy-manifest.yml to deploy the uaa-guard-proxy app.

Once the broker is deployed, you can register it:

cf create-service-broker \
    uaa-auth-broker \
    $GUARD_BROKER_USERNAME \
    $GUARD_BROKER_PASSWORD \
    https://uaa-guard-broker.my-paas.com \
    --space-scoped

Once you've created the service broker, you must enable-service-access in order to see it in the marketplace.

cf enable-service-access uaa-auth

You should now be able to see the service in the marketplace if you run cf marketplace

Protecting an application with UAA authentication

Now you have setup the supporting components, you can now protect your application with auth!

First create an instance of the service from the marketplace, here we are calling our instance authy

$cf create-service uaa-auth uaa-auth authy

Next, identify the application and its URL which you wish to protect. Here we have an application called hello with a URL of https://hello.my-paas.com

Then you need to bind the service instance you created called authy to the hello.my-paas.com route

⇒  cf bind-route-service my-paas.com authy --hostname hello

Binding may cause requests for route hello.my-paas.com to be altered by service instance authy. Do you want to proceed?> y
Binding route hello.my-paas.com to service instance authy in org org / space space as admin...
OK

You can validate the route for hello is now bound to the authy service instance

⇒  cf routes
Getting routes for org org / space space as admin ...

space          host                domain            port   path   type   apps                service
space          hello               my-paas.com                            hello               authy

All of that looks good, so the last step is to validate we can no longer view the hello application without providing credentials!

⇒  curl -k https://hello.my-paas.com
Unauthorized

and if you visit it you will be redirected to UAA.

Knowing who is logged in

This service will forward a header X-AUTH-USER with the email of the logged in user.

CF WebUI

CF WebUI is a modern single-page web-frontend for Cloud Foundry based on AngularJS and Bootstrap.

Cloud Foundry is the OpenSource Platform as a Service (PaaS) Framework on which many PaaS offerings are based (e.g. Pivotal Web Services, HP Helion, IBM BlueMix, Swisscom Application Cloud, etc.). It allows the developers to provide, manage and scale their application in the cloud very easily and quickly. For end-users Cloud Foundry provides a REST based API and a command line interface (CLI) client. No official free and open source web front-end is currently available.

Getting started

1. Clone the project: git clone https://github.com/icclab/cf-webui <br>
2. Change directory to cf-webUI: cd cf-webUI<br>
3. Change the manifest.yml to your options and the endpoint to your desired Cloud Foundry instance. E.g.: <br>

    ---
    applications:  
    - name: cf-webui  
      memory: 128M  
      host: console-cf-webui-${random-word}  
      path: ./build
      buildpack: staticfile_buildpack
      env: 
        API_ENDPOINT: https://api.run.pivotal.io
        # Use Google DNS by default
        NGINX_RESOLVER: 8.8.8.8
        #Enforce https is used (using x_forwarded_proto check) .Default: enabled
        FORCE_HTTPS: 1

4. Install npm packages: npm install<br>
5. Build the application using Grunt: grunt build<br>
6. Push this application to Cloud Foundry using the cf Command Line Interface (CLI): cf push.<br>
7. Enjoy the CF WebUI!<br>

Disclaimer

The current version is an early release (alpha). It is not yet production-ready. Some features are still to come and it may contain major bugs.

Community & Support

Please report bugs and request features using GitHub Issues. For additional information, you can contact the maintainer directly.

Community discussions about CF-WebUI happen in the CF-WebUI-discuss mailing list. Once you subscribe to the list, you can send mail to the list address: icclab-cf-webui@dornbirn.zhaw.ch. The mailing list archives are also available on the web.

Please follow the ICCLab blog for updates.

License

CF-WebUI is licensed under the Apache License version 2.0. See the LICENSE file.

cf-zsh-autocompletion

Oh My Zsh (or probably any zsh but YMMV) plugin for cf (Cloud Foundry) autocompletion.

See the know issues below for what doesn't work.

Future

Now that the CLI supports plugins, I'm considering abandoning this project in favor of a true CLI plugin.

Installation

Drop the cf directory into your $ZSH/custom/plugins/ (usually ~/.oh-my-zsh/custom/plugins) directory. Then add cf to the plugins line of your .zshrc file. For example here's my .zshrc plugin lines

# Which plugins would you like to load? (plugins can be found in ~/.oh-my-zsh/plugins/*)
# Custom plugins may be added to ~/.oh-my-zsh/custom/plugins/
# Example format: plugins=(rails git textmate ruby lighthouse)
# Add wisely, as too many plugins slow down shell startup.
plugins=(git docker jsontools tmux vagrant bosh cf)

Runtime Options

Personally I think the short hand options to many CF commands clutter up the tab view, so I don't include them in the default output. If you want them included in the output export CF_ZSH_INCLUDE_SHORT=true. The plugin will look for this variable every time so if you want to play with it you an set it on the command line. Otherwise, stick it in your .zshrc had have at it.

Example

Type cf <tab> and watch the magic happen

➜  ~  cf <tab>                                                                      
zsh: do you wish to see all 120 possibilities (60 lines)? y                                                
api                                     passwd
app                                     plugins
apps                                    purge-service-offering
auth                                    push
bind-running-security-group             quota
... and on and on

➜  ~  cf create-<tab>                                                                                                  
create-buildpack              create-security-group         create-space
create-domain                 create-service                create-space-quota
create-org                    create-service-auth-token     create-user
create-quota                  create-service-broker         create-user-provided-service
create-route                  create-shared-domain

Known Issues

It doesn't provide extended help for commands, which would be nice. For instance when you type cf push <tab> you don't get the usage.

It doesn't know about parameters for every command yet. It will prompt with spaces, orgs and apps for some commands.

El Problemo?

Open an issue or submit a PR please!

Tracker

Is avaliable here

CF Playground

The goal of this project is to provide an easily accessible environment for users who want to experience Cloud Foundry, without having to setup and to learn the operation of the platform. CF Playground provides an interactive tutorial.

Setting up CF Playground

The following instruction is for OSX/Linux, windows support is coming soon. You will need to host your own Cloud Foundry environment (bosh-lite or any full deployment)

1) Ensure that Go version 1.2+ is installed on the system

2) Setup the GOPATH

export GOPATH=~/go
export PATH=$GOPATH/bin:$PATH

3) Download CF PLayground

go get github.com/cloudfoundry-community/cfplayground
cd $GOPATH/src/github.com/cloudfoundry-community/cfplayground

*(Ignore any warnings about "no buildable Go source files")

4) Create a config file config.json under config/ with the info of your Cloud Foundry environment, a sample config file is provided for reference config/sameple_config.json

* if no config.json is found, boshlite_config.json will be used to target a local boshlite environment.

5) Run CF Playground

go run main.go

• If you are running CF Playground under Linux, download Linux CF CLI Binary, rename and replace the pcf file under assets/cf/ with the downloaded binary.

Limitation

• No Windows support (coming soon)
• Arbitrary app pushing (functioning, improvement to be made)
• Temp user account/space clean up (work in progress)
• Restore user session (functioning, improvement to be made)
• The supported CF commands are:
  • cf push
  • cf apps
  • cf app {app name}
  • cf delete {app name}

18F Cloud Foundry Deck

Tech Stack

• Go (v1.5 required) for the backend server.

• AngularJS for the frontend.

Setup

Create a Client with UAAC

• Make sure UAAC is installed.
• Target your UAA server. uaac target <uaa.your-domain.com>
• Login with your current UAA account. uaac token client get <your admin account> -s <your uaa admin password>
• Create client account:

  uaac client add <your-client-id> \
  --authorities cloud_controller.admin,cloud_controller.read,cloud_controller.write,openid,scim.read \
  --authorized_grant_types authorization_code,client_credentials,refresh_token \
  --scope cloud_controller.admin,cloud_controller.read,cloud_controller.write,openid,scim.read \
  -s <your-client-secret>

• Unable to create an account still? Troubleshoot here

Set the environment variables

If you are testing locally, export these variables. If you are deploying to cloud foundry, modify the manifest.yml

• CONSOLE_CLIENT_ID: Registered client id with UAA.
• CONSOLE_CLIENT_SECRET: The client secret.
• CONSOLE_HOSTNAME: The URL of the service itself.
• CONSOLE_LOGIN_URL: The base URL of the auth service. i.e. https://login.domain.com
• CONSOLE_UAA_URL: The URL of the UAA service. i.e. https://uaa.domain.com
• CONSOLE_API_URL: The URL of the API service. i.e. http://api.domain.com
• CONSOLE_LOG_URL: The URL of the loggregator service. i.e. http://loggregator.domain.com
• PPROF_ENABLED: An optional variable. If set to true or 1, will turn on /debug/pprof endpoints as seen here

Front end

Install front end dependencies

npm install

Running locally

• Make sure all of your environment variables are set as mentioned above.
• Install godep
• Run godep restore to get all third party code
• go run server.go
• Navigate browser to http://localhost:9999

Unit Testing

Running Go unit tests

• go test ./...

Running Angular unit tests

Test can then be run with the command:

npm run tests

To get a viewable coverage report change the coverageReport object in karma.conf.js from json to html

coverageReporter: {
    type: 'html',
    dir: 'coverage',
    subdir: '.'
}

Acceptance Tests

This project currently uses a combination of Agouti + Ginkgo + Gomega to provide BDD acceptance testing. All the acceptance tests are in the 'acceptance' folder.

Setup

• Make sure you have PhantomJS installed: brew install phantomjs
• Install aogut: go get github.com/sclevine/agouti
• Install ginkgo go get github.com/onsi/ginkgo/ginkgo
• Install gomega go get github.com/onsi/gomega
• To run locally, in addition to the variables in the "Set the environmnent variables" section, you will need to set two more variables in your environment
• CONSOLE_TEST_USERNAME: The username of the account you want the tests to use to login into your CONSOLE_LOGIN_URL
• CONSOLE_TEST_PASSWORD: The password of the account you want the tests to use to login into your CONSOLE_LOGIN_URL
• CONSOLE_TEST_ORG_NAME: The test organization the user should be navigating to.
• CONSOLE_TEST_SPACE_NAME: The test space the user should be navigating to.
• CONSOLE_TEST_APP_NAME: The test app the user should be navigating to.
• CONSOLE_TEST_HOST: The host that the app can create a mock route for.
• CONSOLE_TEST_DOMAIN: The domain for the mock route.

Running acceptance tests

• cd acceptance && go test -tags acceptance

Deploying

• cf push <optional-app-name>

CI

This project uses Travis-CI

• The following environment variables need to be set in plain text in the global env section:
  • CONSOLE_API_URL, CONSOLE_UAA_URL, CONSOLE_LOG_URL, CONSOLE_LOGIN_URL, CONSOLE_HOSTNAME="http://localhost:9999", CONSOLE_TEST_ORG_NAME, CONSOLE_TEST_SPACE_NAME, and CONSOLE_TEST_APP_NAME
• In case you fork this project for your own use (no need to do this if forking to make a pull request), you will need to use the Travis-CI CLI tool to re-encrypt all the environment variables.
  • travis encrypt CONSOLE_CLIENT_ID='<your client id>' --add env.global
  • travis encrypt CONSOLE_CLIENT_SECRET='<your client secret>' --add env.global
  • travis encrypt CONSOLE_TEST_PASSWORD='<the test user account password>' --add env.global
  • travis encrypt CONSOLE_TEST_USERNAME='<the test user account username>' --add env.global
  • travis encrypt CF_USERNAME='<the user account username used to deploy>' --add env.global
  • travis encrypt CF_PASSWORD='<the user account password used to deploy>' --add env.global

What’s a Deck?

From Wikipedia:

The Sprawl trilogy (also known as the Neuromancer, Cyberspace, or Matrix trilogy) is William Gibson's first set of novels, composed of Neuromancer (1984), Count Zero (1986), and Mona Lisa Overdrive (1988).

Cyberspace Deck

Also called a "deck" for short, it is used to access the virtual representation of the matrix. The deck is connected to a tiara-like device that operates by using electrodes to stimulate the user's brain while drowning out other external stimulation. As Case describes them, decks are basically simplified simstim units.

Cloud Foundry CLI Plugin Repository (CLIPR)

This is a public repository for community created CF CLI plugins. To submit your plugin approval, please submit a pull request according to the guidelines below.

*If you are looking for information about the Plugin Repo Server, please go here

Submitting Plugins

1. You need to have git installed
2. Clone this repo git clone https://github.com/cloudfoundry-incubator/cli-plugin-repo

3. Include your plugin information in repo-index.yml, here is an example of a new plugin entry

   - name: new_plugin
   description: new_plugin to be made available for the CF community
   version: 1.0.0
   created: 2015-1-31
   updated: 2015-1-31
   company:
   authors:
   - name: Sample-Author
     homepage: http://github.com/sample-author
     contact: contact@sample-author.io
   homepage: http://github.com/sample-author/new_plugin
   binaries:
   - platform: osx 
     url: https://github.com/sample-author/new_plugin/releases/download/v1.0.0/echo_darwin
     checksum: 2a087d5cddcfb057fbda91e611c33f46
   - platform: win64 
     url: https://github.com/sample-author/new_plugin/releases/download/v1.0.0/echo_win64.exe
     checksum: b4550d6594a3358563b9dcb81e40fd66
   - platform: linux32
     url: https://github.com/sample-author/new_plugin/releases/download/v1.0.0/echo_linux32
     checksum: f6540d6594a9684563b9lfa81e23id93

   Please make sure the spacing and colons are correct in the entry. The following descibes each field's usage.

   Field	Description
   name	Name of your plugin, must not conflict with other existing plugins in the repo.
   description	Describe your plugin in a line or two. This desscription will show up when your plugin is listed on the command line
   version	Version number of your plugin, in [major].[minor].[build] form
   created	Date of first submission of the plugin, in year-month-day form
   updated	Date of last update of the plugin, in year-month-day form
   company	Optional field detailing company or organization that created the plugin
   authors	Fields to detail the authors of the plugin name: name of author homepage: Optional link to the homepage of the author contact: Optional ways to contact author, email, twitter, phone etc ...
   homepage	Link to the homepage where the source code is hosted. Currently we only support open source plugins
   binaries	This section has fields detailing the various binary versions of your plugin. To reach as large an audience as possible, we encourage contributors to cross-compile their plugins on as many platforms as possible. Go provides everything you need to cross-compile for different platforms platform: The os for this binary. Supports osx, linux32, linux64, win32, win64 url: Link to the binary file itself checksum: SHA-1 of the binary file for verification

4. After making the changes, fork the repository

5. Add your fork as a remote

   cd $GOPATH/src/github.com/cloudfoundry-incubator/cli-plugin-repo
   git remote add your_name https://github.com/your_name/cli-plugin-repo

6. Push the changes to your fork and submit a Pull Request

Running your own Plugin Repo Server

Included as part of this repository is the CLI Plugin Repo (CLIPR), a reference implementation of a repo server. For information on how to run CLIPR or how to write your own, please see the CLIPR documentation here.

Cloud Foundry CLI

This is the official command line client for Cloud Foundry.

You can follow our development progress on Pivotal Tracker.

Getting Started

Download and run the installer for your platform from the Downloads Section.

Once installed, you can log in and push an app.

$ cd [my-app-directory]
$ cf api api.[my-cloudfoundry].com
Setting api endpoint to https://api.[my-cloudfoundry].com...
OK

$ cf login
API endpoint: https://api.[my-cloudfoundry].com

Email> [my-email]

Password> [my-password]
Authenticating...
OK

$ cf push

Further Reading and Getting Help

• You can find further documentation at the docs page for the CLI here.
• There is also help available in the CLI itself; type cf help for more information.
• Each command also has help output available via cf [command] --help or cf [command] -h.
• For development guide on writing a cli plugin, see here.
• Finally, if you are still stuck or have any questions or issues, feel free to open a GitHub issue.

Downloads

Latest stable: Download the installer or compressed binary for your platform:

From the command line: Download examples with curl for Mac OS X and Linux

# ...download & extract Mac OS X binary
$ curl -L "https://cli.run.pivotal.io/stable?release=macosx64-binary&source=github" | tar -zx
# ...or Linux binary
$ curl -L "https://cli.run.pivotal.io/stable?release=linux64-binary&source=github" | tar -zx
# ...and confirm you got the version you expected
$ ./cf --version
cf version x.y.z-...

Experimental: Install CF for OSX through Homebrew via the pivotal's homebrew-tap:

$ brew tap pivotal/tap
$ brew install cloudfoundry-cli

Also, edge binaries are published for Mac OS X 64 bit, Windows 64 bit and Linux 64 bit with each new 'push' that passes though CI. These binaries are not intended for wider use; they're for developers to test new features and fixes as they are completed.

Releases: 32 bit releases and information about all our releases can be found here

Troubleshooting / FAQs

Known Issues

• .cfignore used in cf push must be in UTF8 encoding for CLI to interpret correctly.

Linux

• "bash: .cf: No such file or directory". Ensure that you're using the correct binary or installer for your architecture. See http://askubuntu.com/questions/133389/no-such-file-or-directory-but-the-file-exists

Filing Bugs

For simple bugs (eg: text formatting, help messages, etc), please provide

• the command you ran
• what occurred
• what you expected to occur

For bugs related to HTTP requests or strange behavior, please run the command with env var CF_TRACE=true and provide

• the command you ran
• the trace output
• a high-level description of the bug

For panics and other crashes, please provide

• the command you ran
• the stack trace generated (if any)
• any other relevant information

Forking the repository for development

1. Install Go
2. Ensure your $GOPATH is set correctly
3. Install godep
4. Get the cli source code: go get github.com/cloudfoundry/cli
   • (Ignore any warnings about "no buildable Go source files")
5. Run godep restore (note: this will modify the dependencies in your $GOPATH)
6. Fork the repository
7. Add your fork as a remote: cd $GOPATH/src/github.com/cloudfoundry/cli && git remote add your_name https://github.com/your_name/cli

Building

To prepare your build environment, run go get -u github.com/jteeuwen/go-bindata/...

1. Run ./bin/build
2. The binary will be built into the ./out directory.

Optionally, you can use bin/run to compile and run the executable in one step.

If you want to run the tests with ginkgo, or build with go build you should first run bin/generate-language-resources. bin/build and bin/test generate language files automatically.

Developing

1. Install Mercurial
2. Run go get golang.org/x/tools/cmd/vet
3. Write a Ginkgo test.
4. Run bin/test and watch the test fail.
5. Make the test pass.
6. Submit a pull request to the master branch.

*__ For development guide on writing a cli plugin, see here**

Contributing

Major new feature proposals are given as a publically viewable google document with commenting allowed and discussed on the cf-dev mailing list.

Pull Requests

Pull Requests should be made against the master branch.

Architecture overview

A command is a struct that implements this interface:

type Command interface {
    MetaData() CommandMetadata
    SetDependency(deps Dependency, pluginCall bool) Command
    Requirements(requirementsFactory requirements.Factory, context flags.FlagContext) (reqs []requirements.Requirement, err error)
    Execute(context flags.FlagContext)
}

Source code

Metadata() is just a description of the command name, usage and flags:

type CommandMetadata struct {
    Name            string
    ShortName       string
    Usage           string
    Description     string
    Flags           map[string]flags.FlagSet
    SkipFlagParsing bool
    TotalArgs       int
}

Source code

Requirements() returns a list of requirements that need to be met before a command can be invoked.

Execute() is the method that your command implements to do whatever it's supposed to do. The context object provides flags and arguments.

When the command is run, it communicates with api using repositories (they are in cf/api).

SetDependency() is where a command obtains its dependencies. Dependencies are typically declared as an interface type, and not a concrete type, so tests can inject a fake. The bool argument pluginCall indicates whether the command is invoked by one of the CLI's plugin API methods.

Dependencies are injected into each command, so tests can inject a fake. This means that dependencies are typically declared as an interface type, and not a concrete type. (see cf/command_registry/dependency.go)

Some dependencies are managed by a repository locator in cf/api/repository_locator.go.

Repositories communicate with the api endpoints through a Gateway (see cf/net).

Models are data structures related to Cloud Foundry (see cf/models). For example, some models are apps, buildpacks, domains, etc.

Managing dependencies

Command dependencies are managed by the command registry package. The app uses the package (in cf/command_registry/dependency.go)to instantiate them, this allows not sharing the knowledge of their dependencies with the app itself.

For commands that use another command as dependency, command_registry is used for retrieving the command dependency. For example, the command restart has a dependency on command start and stop, and this is how the command dependency is retrieved: restart.go

As for repositories, we use the repository locator to handle their dependencies. You can find it in cf/api/repository_locator.go.

Example command

Create Space is a good example of a command. Its tests include checking arguments, requiring the user to be logged in, and the actual behavior of the command itself. You can find it in cf/commands/space/create_space.go.

i18n

All pull requests which include user-facing strings should include updated translation files. These files are generated/ maintained using i18n4go.

To add/ update translation strings run the command i18n4go -c fixup. For each change or update, you will be presented with the choices new or upd. Type in the appropriate choice. If upd is chosen, you will be asked to confirm which string is being updated using a numbered list.

Current conventions

Creating Commands

Resources that include several commands have been broken out into their own sub-package using the Resource name. An example of this convention is the Space resource and package (see cf/commands/space)

In addition, command file and methods naming follows a CRUD like convention. For example, the Space resource includes commands such a CreateSpace, ListSpaces, DeleteSpace, etc.

Creating Repositories

Although not ideal, we use the name "Repository" for API related operations as opposed to "Service". Repository was chosen to avoid confusion with Service model objects (i.e. creating Services and Service Instances within Cloud Foundry).

By convention, Repository methods return a model object and an error. Models are used in both Commands and Repositories to model Cloud Foundry data. This convention provides a consistent method signature across repositories.

Apache CloudStack

Apache CloudStack is open source software designed to deploy and manage large networks of virtual machines, as a highly available, highly scalable Infrastructure as a Service (IaaS) cloud computing platform. CloudStack is used by a number of service providers to offer public cloud services, and by many companies to provide an on-premises (private) cloud offering, or as part of a hybrid cloud solution.

CloudStack is a turnkey solution that includes the entire "stack" of features most organizations want with an IaaS cloud: compute orchestration, Network-as-a-Service, user and account management, a full and open native API, resource accounting, and a first-class User Interface (UI).

CloudStack currently supports the most popular hypervisors: VMware vSphere, KVM, XenServer, XenProject and Hyper-V as well as OVM and LXC containers.

Users can manage their cloud with an easy to use Web interface, command line tools, and/or a full-featured query based API.

For more information on Apache CloudStack, please visit the website

Who Uses CloudStack?

• There are more than 150 known organizations using Apache CloudStack (or a commercial distribution of CloudStack). Our users include many major service providers running CloudStack to offer public cloud services, product vendors who incorporate or integrate with CloudStack in their own products, organizations who have used CloudStack to build their own private clouds, and systems integrators that offer CloudStack related services.

• See our case studies highlighting successful deployments of Apache CloudStack.

• See the up-to-date list of current users.

• If you are using CloudStack in your organization and your company is not listed above, please complete our brief adoption survey. We're happy to keep your company name anonymous if you require.

Getting Started

• Download a released version
• Build from source with the instructions in the INSTALL.md file.

Getting Source Repository

Apache CloudStack project uses Git. The official Git repository is at:

https://gitbox.apache.org/repos/asf/cloudstack.git

And a mirror is hosted on Github:

https://github.com/apache/cloudstack

The Github mirror is strictly read only and provides convenience to users and developers to explore the code and for the community to accept contributions via Github pull requests.

Links

• Documentation
• Developer wiki
• Release notes
• Design documents
• API documentation
• How to contribute

Getting Involved and Contributing

Interested in helping out with Apache CloudStack? Great! We welcome participation from anybody willing to work The Apache Way and make a contribution. Note that you do not have to be a developer in order to contribute to Apache CloudStack. We need folks to help with documentation, translation, promotion etc. See our contribution page.

If you're interested in learning more or participating in the Apache CloudStack project, the mailing lists are the best way to do that. While the project has several communications channels, the mailing lists are the most active and the official channels for making decisions about the project itself.

Mailing lists:

• Development Mailing List
• Users Mailing List
• Commits Mailing List
• Issues Mailing List
• Marketing Mailing List

IRC, join us on irc.freenode.net on:

• #cloudstack: General Apache CloudStack conversation and end user support
• #cloudstack-dev: Development discussions

Report and/or check bugs on JIRA and check our developer page for contributing code.

News and Events

• Blog
• Twitter
• Events and meetup

Reporting Security Vulnerabilities

If you've found an issue that you believe is a security vulnerability in a released version of CloudStack, please report it to security@cloudstack.apache.org with details about the vulnerability, how it might be exploited, and any additional information that might be useful.

For more details, please visit our security page.

License

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

http://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.

Please see the LICENSE file included in the root directory of the source tree for extended license details.

Notice of Cryptographic Software

This distribution includes cryptographic software. The country in which you currently reside may have restrictions on the import, possession, use, and/or re-export to another country, of encryption software. BEFORE using any encryption software, please check your country's laws, regulations and policies concerning the import, possession, or use, and re-export of encryption software, to see if this is permitted. See http://www.wassenaar.org/ for more information.

The U.S. Government Department of Commerce, Bureau of Industry and Security (BIS), has classified this software as Export Commodity Control Number (ECCN) 5D002.C.1, which includes information security software using or performing cryptographic functions with asymmetric algorithms. The form and manner of this Apache Software Foundation distribution makes it eligible for export under the License Exception ENC Technology Software Unrestricted (TSU) exception (see the BIS Export Administration Regulations, Section 740.13) for both object code and source code.

The following provides more details on the included cryptographic software:

• CloudStack makes use of JaSypt cryptographic libraries.
• CloudStack has a system requirement of MySQL, and uses native database encryption functionality.
• CloudStack makes use of the Bouncy Castle general-purpose encryption library.
• CloudStack can optionally interacts with and controls OpenSwan-based VPNs.
• CloudStack has a dependency on and makes use of JSch - a java SSH2 implementation.

CodiMD

CodiMD lets you create real-time collaborative markdown notes on all platforms. Inspired by Hackpad, with more focus on speed and flexibility, and build from HackMD source code. Feel free to contribute.

Thanks for using! :smile:

Table of Contents

• HackMD CE became CodiMD
• Browsers Requirement
• Installation
  • Getting started (Native install)
  • Prerequisite
  • Instructions
  • Heroku Deployment
  • Kubernetes
  • CodiMD by docker container
  • Cloudron
• Upgrade
  • Native setup
• Configuration
  • Environment variables (will overwrite other server configs)
  • Application settings config.json
  • Third-party integration API key settings
  • Third-party integration OAuth callback URLs
• Developer Notes
  • Structure
  • Operational Transformation
• License

HackMD CE became CodiMD

CodiMD was recently renamed from its former name was HackMD. CodiMD is the free software version of HackMD. It was the original Version of HackMD. The HackMD team initiated CodiMD and provided a solid code base. Due to the need of paying bills, A fork was created and called HackMD EE, which is a SaaS (Software as a Service) product available at hackmd.io.

We decided to change the name to break the confusion between HackMD and CodiMD, formally known as HackMD CE, as it never was an open core project.

Just to more confusion: We are still friends with HackMD :heart:

For the whole renaming story, see the related issue

Browsers Requirement

• Chrome >= 47, Chrome for Android >= 47
• Safari >= 9, iOS Safari >= 8.4
• Firefox >= 44
• IE >= 9, Edge >= 12
• Opera >= 34, Opera Mini not supported
• Android Browser >= 4.4

Installation

Getting started (Native install)

Prerequisite

• Node.js 6.x or up (test up to 7.5.0) and <10.x
• Database (PostgreSQL, MySQL, MariaDB, SQLite, MSSQL) use charset utf8
• npm (and its dependencies, especially uWebSockets, node-gyp)
• For building CodiMD we recommend to use a machine with at least 2GB RAM

Instructions

1. Download a release and unzip or clone into a directory
2. Enter the directory and type bin/setup, which will install npm dependencies and create configs. The setup script is written in Bash, you would need bash as a prerequisite.
3. Setup the configs, see more below
4. Setup environment variables which will overwrite the configs
5. Build front-end bundle by npm run build (use npm run dev if you are in development)
6. Modify the file named .sequelizerc, change the value of the variable url with your db connection string For example: postgres://username:password@localhost:5432/codimd
7. Run node_modules/.bin/sequelize db:migrate, this step will migrate your db to the latest schema
8. Run the server as you like (node, forever, pm2)

Heroku Deployment

You can quickly setup a sample Heroku CodiMD application by clicking the button below.

If you deploy it without the button, keep in mind to use the right buildpacks. For details check app.json.

Kubernetes

To install use helm install stable/hackmd.

For all further details, please check out the offical CodiMD K8s helm chart.

CodiMD by docker container

Debian-based version:

Alpine-based version:

The easiest way to setup CodiMD using docker are using the following three commands:

git clone https://github.com/hackmdio/codimd-container.git
cd codimd-container
docker-compose up

Read more about it in the container repository…

Cloudron

Install CodiMD on Cloudron:

Upgrade

Native setup

If you are upgrading CodiMD from an older version, follow these steps:

1. Fully stop your old server first (important)
2. git pull or do whatever that updates the files
3. npm install to update dependencies
4. Build front-end bundle by npm run build (use npm run dev if you are in development)
5. Modify the file named .sequelizerc, change the value of the variable url with your db connection string For example: postgres://username:password@localhost:5432/codimd
6. Run node_modules/.bin/sequelize db:migrate, this step will migrate your db to the latest schema
7. Start your whole new server!

• migrate-to-1.1.0

We deprecated the older lower case config style and moved on to camel case style. Please have a look at the current config.json.example and check the warnings on startup.

Notice: This is not a breaking change right now but in the future

• migration-to-0.5.0

We don't use LZString to compress socket.io data and DB data after version 0.5.0. Please run the migration tool if you're upgrading from the old version.

• migration-to-0.4.0

We've dropped MongoDB after version 0.4.0. So here is the migration tool for you to transfer the old DB data to the new DB. This tool is also used for official service.

Configuration

There are some config settings you need to change in the files below.

./config.json      ----application settings

Environment variables (will overwrite other server configs)

Note: Due to the rename process we renamed all HMD_-prefix variables to be CMD_-prefixed. The old ones continue to work.

Application settings config.json

¹: relative paths are based on CodiMD's base directory

Third-party integration API key settings

Third-party integration OAuth callback URLs

Developer Notes

Structure

codimd/
├── tmp/            --- temporary files
├── docs/           --- document files
├── lib/            --- server libraries
└── public/         --- client files
    ├── css/        --- css styles
    ├── js/         --- js scripts
    ├── vendor/     --- vendor includes
    └── views/      --- view templates

Operational Transformation

From 0.3.2, we started supporting operational transformation. It makes concurrent editing safe and will not break up other users' operations. Additionally, now can show other clients' selections. See more at http://operational-transformation.github.io/

License

License under AGPL.

CodiMD container

Debian based version:

Alpine based version:

Prerequisite

• git (https://git-scm.com/)
• docker (https://www.docker.com/community-edition)
• docker-compose (https://docs.docker.com/compose/install/)

See more here: https://docs.docker.com/

Usage

Get started

1. Install docker and docker-compose, "Docker for Windows" or "Docker for Mac"
2. Run git clone https://github.com/hackmdio/codimd-container.git
3. Change to the directory codimd-container directory
4. Run docker-compose up in your terminal
5. Wait until see the log HTTP Server listening at port 3000, it will take few minutes based on your internet connection.
6. Open http://127.0.0.1:3000

Update

Start your docker and enter the terminal, follow below commands:

cd codimd-contianer ## enter the directory
git pull ## pull new commits
docker-compose pull ## pull new containers
docker-compose up ## turn on

Migrate from docker-hackmd

If you used the docker-hackmd repository before, migrating to codimd-container is easy.

Since codimd-container is basically a fork of docker-hackmd, all you need to do is replacing the upstream URL.

git remote set-url origin https://github.com/hackmdio/codimd-container.git
git pull

Now you can follow the regular update steps.

migration-to-0.5.0

We don't use LZString to compress socket.io data and DB data after version 0.5.0. Please run the migration tool if you're upgrading from the old version.

1. Stop your CodiMD containers
2. Modify docker-compose.yml, add expose ports 5432 to hackmdPostgres
3. docker-compose up to start your codimd containers
4. Backup DB (see below)
5. Git clone above migration-to-0.5.0 and npm install (see more on above link)
6. Modify config.json in migration-to-0.5.0, change its username, password and host to your docker
7. Run migration (see more on above link)
8. Stop your codimd containers
9. Modify docker-compose.yml, remove expose ports 5432 in hackmdPostgres
10. git pull in codimd-container, update to version 0.5.0 (see below)

Backup

Start your docker and enter the terminal, follow below commands:

 docker-compose exec database pg_dump hackmd -U hackmd  > backup.sql

Restore

Similar to backup steps, but last command is

cat backup.sql | docker exec -i $(docker-compose ps -q database) psql -U hackmd

Kubernetes

To install use helm install stable/hackmd.

For all further details, please check out the offical HackMD K8s helm chart.

Custom build

The default setting would use pre-build docker image, if you want to build your own containers uncomment the build section in the docker-compose.yml and edit the config.json.

If you change the database settings and don't use the HMD_DB_URL make sure you edit the .sequelizerc.

License

View license information for the software contained in this image.

Supported Docker versions

This image is officially supported on Docker version 17.03.1-CE.

Support for older versions (down to 1.12) is provided on a best-effort basis.

Please see the Docker installation documentation for details on how to upgrade your Docker daemon.

User Feedback

Issues

If you have any problems with or questions about this image, please contact us through a GitHub issue.

You can also reach many of the project maintainers via our #codimd:matrix.org or the hackmd channel on Gitter.

Contributing

You are invited to contribute new features, fixes, or updates, large or small; we are always thrilled to receive pull requests, and do our best to process them as fast as we can.

Happy CodiMD :smile:

concourse

Concourse is a pipeline-based CI system written in Go.

• Website: concourse.ci
• Documentation:
  • Introduction
  • Setting Up
  • Using Concourse
• Slack:
  • Invitation
  • #general for help and chit-chat
• Roadmap:
  • GitHub Issues
  • Pivotal Tracker

Contributing

Concourse is built on a few components, all written in Go with cutesy aerospace-themed names. This repository is actually its BOSH release, which ties everything together and also serves as the central hub for GitHub issues.

Each component has its own repository:

• ATC is most of Concourse: it provides the API, web UI, and all pipeline orchestration
• Fly is the CLI for interacting with and configuring Concourse pipelines
• TSA is a SSH server used for authorizing worker registration
• Garden is a generic interface for orchestrating containers remotely on a worker
• Baggageclaim is a server for managing caches and artifacts on the workers

To learn more about how they fit together, see Concourse Architecture.