Giter Club home page Giter Club logo

dplz's Introduction

Dplz

Dplz is a deployment system that only requires BASH and SSH. No installation is required on the remote machine in order for it to work.

Dplz is capable of running shell commands and copying any type of file or directory contents. Dplz will also output a report that will tell the user if commands worked or failed.

Right now this software is in beta, but I would love for anyone and everyone to try it out and flood me with issues to work on.

On the horizon

  1. Basic tests
  2. Localhost support
  3. More advanced filtering
  4. Verbose output mode
  5. [insert your suggestion here]

How to install

# Get the project using go get
$ go get github.com/zveinn/dplz
# use go to install
$ go install .

How to get started

  1. Define a server
    • Server files can be located anywhere you please
  2. Define a deployment (optional)
    • Deployment files can be located anywhere you please
  3. Define variables
    • Variable files can be located anywhere you please
  4. Define a script
    • Script files need to be located within your project directory
  5. Run a deployment

Running deployments

# Just run a basic deployment
$ dplz -deployment=[PATH_TO_YOUR_DEPLOYMENT_FILE]
# Run a deployment and ignore warning prompt
$ dplz -deployment=[PATH_TO_YOUR_DEPLOYMENT_FILE] -ignorePrompt
# Run a deployment, ignore the warning prompt and use a filter.
$ dplz -deployment=[PATH_TO_YOUR_DEPLOYMENT_FILE] -ignorePrompt -filter "script.cmd"

# Run a deployment using command line arguments only.
$ dplz -servers=[PATH_TO_SEVER_FOLDER] -project=[PATH_TO_PROJECT_FOLDER] -vars=[PATH_TO_VARIABLES_FILE]

Command Line Arguments

Command line arguments can be combined with deployment json files. If you do combine them, the command line arguments will overwrite the deployment file settings.

	flag.String("deployment", "", "The path to your deployment file")
	flag.String("project", "", "The path to your project files (not needed if using a deployment file)")
	flag.String("servers", "", "The path to your server files (not needed if using a deployment file)")
	flag.String("vars", "", "The path to your variables file (not needed if using a deployment file)")
	flag.Bool("ignorePrompt", false, "Add this flag to skip the confirmation prompt")
	flag.String("filter", "", "Only scripts or commands with this tag will be executed. Example: SCRIPT.CMD ")

Defining servers

Before you define any deployments you need to define a target server.
Each server object contains some basic connections information, custom variables and PRE/POST scripts.

  • Variables are accessable in commands and tamplates.
  • Pre scripts will run BEFORE any other scripts run on that server
  • Post scripts will run AFTER all scripts have been executed.
{
    "hostname": "googlecloud-dev-01",
    "ip": "131.161.181.11",
    "port": "22",
    "key": "/home/user/.ssh/ssh-key",
    "user": "root",
    "variables": {
        "privateIP": "11.11.11.11",
        "dns": "1.1.1.1"
    },
    "pre": [
        {"run": "echo 'This runs before all the scripts'"}
    ],
    "post": [
        {"run": "echo 'This runs after all the scripts'"}
    ]
}

Defining deployments

This part is purely optional. You can input all of the below parameters as command line arguments as well. But for the sake of replicating deployments we decided to add this "highest level object".
A Deployment will define the location of your server json files, project json files and the variables json file.

  • NOTE: Deployment wide variables are only configurable inside a deployment json file
{
    "servers": "PATH_TO_YOUR_SERVER_FOLDER",
    "project": "PATH_TO_YOUR_PROJECT_FOLDER",
    "vars": "PATH_TO_YOUR_VARIABLES_FILE",
    "variables": {
        "example": "This is an example custom variable"
    }
}

Defining variables

Variables are defined in a json file and the vars flag is used to load variables each time you run a deployment.

  • These variables are available inside commands and templates.
{
    "testVariable": "Dev variables loaded",
    "redisIP": "198.168.0.66",
    "sqlIP": "192.168.0.67"
}

Defining scripts

This is a basic script, it will contain some variables and commands to execute. There are three types of commands:

  1. Run - Only runs a commands on the server
  2. File - Copies a file AS IS to the server (follows SCP syntax)
  3. Template - Copies a file AND replaces variables (follows SCP syntax)
{
    "name": "Basic deployment",
    "filter": "basic",
    "variables": {
        "name": "Some random name",
        "testVariable": "Here is some random text you can inject into a file..."
    },
    "cmd": [
        {
            "template": {
                "src": "files/webserver.template.conf",
                "dst": "/home/sveinn/meow/test.template",
                "mode": "0777"
            },
            "filter": "templates",
            "async": true
        },
        {
            "file": {
                "src": "files/meow",
                "dst": "/home/sveinn/meow/test.file",
                "mode": "0777"
            },
            "filter": "files",
            "async": true
        },
        {
            "run": "mkdir /home/sveinn/meow",
            "filter": "dir",
            "async": false
        },
        {
            "directory": {
                "src": "files",
                "dst": "/home/sveinn/meow",
                "mode": "0777"
            },
            "filter": "dir",
            "async": false
        },
        {
            "run": "uname -a",
            "filter": "uname",
            "async": false
        },
        {
            "run": "ls -la",
            "filter": "list"
        }
    ]
}

Ordering of scripts

Scripts do not have any guarentee to be run in a particular order. The ordering is solely based on the directory walking machanism, which makes it non-dependable.

Ordering of commands

Commands present inside scripts will always be executed in order. Except if the async tag is specified, then ordering is not guaranteed for the commands flagged as async.

Filtering

The filtering is currently a strict matching filter. The filter tag and the filter variables on the script or command need to match exactly.

Run a certain script and commands that match the filter

  • -filter scripts.cmd

Run a certain set of commands inside all filters

  • -filter *.cmd

Run all commands inside a scripts matching the filter

  • -filter scripts.*

dplz's People

Contributors

zveinn avatar 0xmalvee avatar lohanguedes avatar dependabot[bot] avatar shtripat avatar

Stargazers

Maikon Alexandre  avatar  avatar Nino Annighoefer avatar Lubomir Anastasov avatar Dave Cottlehuber avatar Louis Pilfold avatar  avatar

Watchers

Lucian avatar  avatar

dplz's Issues

replace local and remote with src and dst

	{
		"template": {
			"local": "files/node-supervisor.template.conf",
			"remote": "/etc/supervisor/conf.d/{[NodeTag]}.conf",
			"mode": "0777"
		},
		"filter": "config",
		"async": false
	},

Modification of cli parameters

Remove project concept

Remove deployment concept

Add/Change --servers/-s cli input and --variables/-v

$ dplz -s server1.json server2.json server3.json ...
$ dplz -s *server.json (PRERFIX)
$ dplz -s server_*.json (WILDCARD)
$ dplz -s x/*_server_*.json 

Support password authentication

support plain text authentication for the initial deployment step for the servers which can't be deployed with a preset ssh-key

Support local machine script execution

This would probably include adding a local tag to CMD struct to indicate we want to run this locally. Or maybe there is a better way, look into this before implementing.

Reason for addition:
Sometimes you want to build a binary locally and then deploy it to a server and you want to do both in a script file

Change the way we use dplz.

Components (json files)

  • [] variables

    • These are global variables .. when used for scripts and templates they are simply references by {[ X ]}.
  • [] servers

    • There are server specific variables, these are references as {[ server.X ]}
  • [] scripts

    • There are script specific variables, these are references as {[ script.X ]}
  • Deployment

    • This combines servers, scripts and variables into one bundle.
    • There are script specific variables, these are references as {[ deployment.X ]}
{
  "varFiles": [],
  "serverFiles": [],
  "scriptFiles": [],
  "variables": {
    "name": "Random deployment variables !"
  }
}

Other:

  • Template files ( these files are references in the scripts )

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.