hashrocket / gatling Goto Github PK

I like to have separate deploys of code for each environment - dev runs a newer version than test, which is newer than production. However, each server in my setup is semi-disposable, and I have a startup script that runs to bring each server to life. If possible, I really want this script to be able to push the correct version of the code, soGatling deploys the correct version.

Is there any plan (or are you open to) implementing some kind of environment/version correlation in Gatling? What I am picturing is something like this:

• Before doing anything of consequence, Gatling checks what version this server should be running.
  • This should probably just be whatever the Mix env is set to.
  • The version corresponds to a particular tag in git.
• Gatling examines what version it is currently on. If it is the same, it does nothing. If its gone up, then it proceeds as it does now.

Why do I want to do this? It makes life easier, to me at least. All servers can have the same git commits pushed to them (I could perhaps even automate this) , and I can destroy and recreate the servers without any special handling. With this approach, I can get hot upgrades most of the time, and easy re-creation for when that makes more sense.

Of course, i'm still new to Elixir deployment, so I could be totally off-base with what I am looking to do. I am willing to implement this if you think its a worthy endeavor.

The configuration files domains, deploy.exs and upgrade.exs should not be cluttering the root directory, in my opinion.

Maybe move them into .gatling/ or config/gatling/?

This is just a suggestion, I like the project so far.

Currently the --env=prod setting is hard coded into the upgrade task, would be useful for staging/etc environments to allow "--env=#{env}"

Just wondering what the best way is to roll back releases. Does it have to be done manually? or is there a way to do that with Gatling?

Along with this comment really:
#8 (comment)

Testing against a clean deploy and upgrade on DigialOcean > Ubuntu > root test vm., which works fine on the git push now 👍 CentOs testing next after...

I wanted to complete the deployment loop with the callbacks to do npm/asset work as looking to mix in some elm magic before digest. This is

Followed the documented notes on a deploy.exs and upgrade.exs. As soon as I add in the bash command, it errors on

Compressing objects: 100% (5/5), done.
Writing objects: 100% (6/6), 481 bytes | 0 bytes/s, done.
Total 6 (delta 3), reused 0 (delta 0)
remote: ** (CompileError) /root/briskoda_hub/upgrade.exs:4: undefined function bash/3
remote:     (stdlib) lists.erl:1338: :lists.foreach/2
remote:     (stdlib) erl_eval.erl:670: :erl_eval.do_apply/6
remote: 

So upgrade.exs contains:

defmodule BriskodaHub.UpgradeCallbacks do

  def before_mix_digest(env) do
    bash("mkdir", ~w[-p priv/static], cd: env.build_dir) # optional: release may complain about this directory not existing
    bash("npm", ~w[install], cd: env.build_dir)
    bash("brunch", ~w[build --production], cd: env.build_dir)
    # bash("mix", ~w[phoenix.digest -o public/static], cd: env.build_dir)
    env
  end
end

So I'm trying to figure this out without copying the bash features in. I've currently only got this on the deploy server in the repository folder. so /root/briskoda_hub/upgrade.exs

In the meantime, I'm posting this as the many eyes will be faster than my noggin to the blindingly obvious mistake I've made...

Thanks for an awesome tool so far.

When calling mix build the task should:

• create a build
• move the build into gatling_archives
• update the README.md file in gatling_archives/README.md to say Current default version x.x.x

Counting objects: 4, done. Delta compression using up to 8 threads. Compressing objects: 100% (4/4), done. Writing objects: 100% (4/4), 375 bytes | 0 bytes/s, done. Total 4 (delta 3), reused 0 (delta 0) remote: $ mix deps.get (/home/james/charter) remote: Running dependency resolution remote: All dependencies up to date remote: $ mix compile --force (/home/james/charter) remote: Compiling 49 files (.ex) remote: warning: unused import Plug.Conn remote: web/controllers/auth.ex:3 remote: remote: warning: unused alias Priority remote: web/controllers/ticket_controller.ex:5 remote: remote: warning: unused alias Sprint remote: web/controllers/ticket_controller.ex:6 remote: remote: Generated charter app remote: $ mix phoenix.digest -o public/static (/home/james/charter) remote: Check your digested files at "public/static" remote: $ mix release --no-confirm-missing (/home/james/charter) remote: Building release with MIX_ENV=prod. remote: remote: You have dependencies (direct/transitive) which are not in :applications! remote: The following apps should be added to :applications in mix.exs: remote: remote: phoenix_haml => phoenix_haml is missing from charter remote: guardian => guardian is missing from charter remote: remote: This is an upgrade, verifying appups exist for updated dependencies.. remote: ==> All dependencies have appups ready for release! remote: ==> Generated .appup for charter 0.0.1475342942 -> 0.0.1475343466 remote: ==> The release for charter-0.0.1475343466 is ready! remote: ==> You can boot a console running your release with$ rel/charter/bin/charter console remote: $ service charter upgrade 0.0.1475343466 remote: Release 0.0.1475343466 not found, attempting to unpack releases/0.0.1475343466/charter.tar.gz remote: Unpacked successfully: "0.0.1475343466" remote: Generating vm.args/sys.config for upgrade... remote: sys.config ready! remote: vm.args ready! remote: Release 0.0.1475343466 is already unpacked, now installing. remote: Installed Release: 0.0.1475343466 remote: Made release permanent: "0.0.1475343466" remote: $ nginx -s reload remote: nginx: [emerg] invalid port in upstream "localhost:" in /etc/nginx/sites-enabled/charter:10

`server {
listen 80;
server_name www.mydomain.com;

location / {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_redirect off;
proxy_pass http://localhost:;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}`

Any ideas?

I've been building releases by hand on the server, because when I push with git, Gatling seems to run through the the build process but doesn't create a .tar.gz file because it's not looking for the .rel in the same directory where it built it. My solution so far has then been to re-build the release manually on the server with "mix release", which works, and then kill and restart the release by hand. (I'm also providing the port manually, as described #38. )

This procedure works and I can get the site running. Gatling did successfully do all the work of configuring nginx, which is a huge boon, but I'd love to get it running 100%.

Here's the steps I'm going through, with what's in my releases directory at each step:

Starting with a working version 0.1.0

deploy@my-app:~/tracker$ tree -L 2 _build/prod/rel/tracker/releases/
_build/prod/rel/tracker/releases/
├── 0.1.0
│   ├── commands
│   ├── hooks
│   ├── start_clean.boot
│   ├── sys.config
│   ├── tracker.boot
│   ├── tracker.rel
│   ├── tracker.script
│   ├── tracker.sh
│   ├── tracker.tar.gz
│   └── vm.args
├── RELEASES
└── start_erl.data

3 directories, 10 files

STEP 1: Attempt to deploy from local machine with git push, watch it fail when it tries to copy tracker.tar.gz

[18:30:36 tracker (master)]$ git push production master
Counting objects: 11, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (10/10), done.
Writing objects: 100% (11/11), 930 bytes | 0 bytes/s, done.
Total 11 (delta 6), reused 0 (delta 0)
remote: $ mix deps.get (/home/deploy/tracker)
remote: Running dependency resolution...
remote: All dependencies up to date
remote: $ mix compile --force (/home/deploy/tracker)
remote: Compiling 15 files (.ex)
remote: Generated tracker app
remote: $ npm install (/home/deploy/tracker)
remote: npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@^1.0.0 (node_modules/chokidar/node_modules/fsevents):
remote: npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for [email protected]: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
remote: $ npm run deploy (/home/deploy/tracker)
remote:
remote: > @ deploy /home/deploy/tracker
remote: > brunch build --production
remote:
remote: 22 Jan 02:37:24 - info: compiling
remote: 22 Jan 02:37:29 - info: compiling.
remote: 22 Jan 02:37:29 - info: compiled 10 files into 2 files, copied 12 in 10.3 sec
remote: $ mix phoenix.digest (/home/deploy/tracker)
remote: Check your digested files at "priv/static"
remote: /home/deploy/tracker/rel/config.exs found
remote: $ mix release --upgrade --upfrom= --warnings-as-errors --env=prod (/home/deploy/tracker)
remote: ==> Assembling release..
remote: ==> Building release tracker:0.1.1 using environment prod
remote: ==> Including ERTS 8.2 from /usr/lib/erlang/erts-8.2
remote: ==> Failed to build release:
remote:     Missing .rel for tracker: at _build/prod/rel/tracker/releases/tracker.rel
remote: ** (File.CopyError) could not copy from "/home/deploy/tracker/_build/prod/rel/tracker/releases/0.1.1/tracker.tar.gz" to "/home/deploy/deployments/tracker/releases/0.1.1/tracker.tar.gz": no such file or directory
remote:     (elixir) lib/file.ex:524: File.cp!/3
remote:     lib/gatling/tasks/upgrade.ex:102: Mix.Tasks.Gatling.Upgrade.copy_release_to_upgrade/1
remote:     lib/gatling/tasks/upgrade.ex:123: Mix.Tasks.Gatling.Upgrade.call/2
remote:     lib/gatling/tasks/upgrade.ex:33: Mix.Tasks.Gatling.Upgrade.upgrade/1
remote:     (mix) lib/mix/task.ex:294: Mix.Task.run_task/3
remote:     (mix) lib/mix/cli.ex:58: Mix.CLI.run_task/2
remote:
To deploy@<MY APP>.org:tracker
   3f2e7c1..5651892  master -> master

NOTE: I see in the error message above that it is looking for tracker.rel in _build/prod/rel/tracker/releases/tracker.rel, but if we look at the tree actually in _build/prod/rel/tracker/releases/0.1.1/

deploy@my-app:~/tracker$ tree -L 2 _build/prod/rel/tracker/releases/
_build/prod/rel/tracker/releases/
├── 0.1.0
│   ├── commands
│   ├── hooks
│   ├── start_clean.boot
│   ├── sys.config
│   ├── tracker.boot
│   ├── tracker.rel
│   ├── tracker.script
│   ├── tracker.sh
│   ├── tracker.tar.gz
│   └── vm.args
├── 0.1.1
│   ├── start_clean.boot
│   ├── sys.config
│   ├── tracker.boot
│   ├── tracker.rel
│   ├── tracker.script
│   ├── tracker.sh
│   └── vm.args
├── RELEASES
└── start_erl.data
4 directories, 17 files

STEP 2: build a release by hand on the server
if the env is set, running mix release on the server results in the files being built correctly.

deploy@my-app:~/tracker$ PORT=39491 MIX_ENV=prod sudo --preserve-env mix release --env prod
==> Assembling release..
==> Building release tracker:0.1.1 using environment prod
==> Including ERTS 8.2 from /usr/lib/erlang/erts-8.2
==> Packaging release..
==> Release successfully built!
    You can run it in one of the following ways:
      Interactive: _build/prod/rel/tracker/bin/tracker console
      Foreground: _build/prod/rel/tracker/bin/tracker foreground
      Daemon: _build/prod/rel/tracker/bin/tracker start
      
      
deploy@my-app:~/tracker$ tree -L 2 _build/prod/rel/tracker/releases/
_build/prod/rel/tracker/releases/
├── 0.1.0
│   ├── commands
│   ├── hooks
│   ├── start_clean.boot
│   ├── sys.config
│   ├── tracker.boot
│   ├── tracker.rel
│   ├── tracker.script
│   ├── tracker.sh
│   ├── tracker.tar.gz
│   └── vm.args
├── 0.1.1
│   ├── commands
│   ├── hooks
│   ├── start_clean.boot
│   ├── sys.config
│   ├── tracker.boot
│   ├── tracker.rel
│   ├── tracker.script
│   ├── tracker.sh
│   ├── tracker.tar.gz
│   └── vm.args
├── RELEASES
└── start_erl.data

6 directories, 18 files

Step 3: Now I can deploy the new version by killing the old processes and starting the new one

deploy@my-app:~/tracker$ ps waux | grep tracker
[ snip ]
deploy@my-app:~/tracker$ sudo kill 7239; sudo kill 7240; sudo kill 7278; PORT=39491 --preserve-env sudo _build/prod/rel/tracker/bin/tracker start

That gets the site working again. If you have any thoughts/advice on debugging the issues in step 2 above, i'd be most gracious.

Hello I have deployed a Phoenix app on Digital Ocean with Gatling, Distillery, and Nginx but I wanted to change the domain name of my application but the changes are not reflected even after restarting Nginx and the Daemon process.

The following is my configuration
config/prod.exs:

config :kappamon, Kappamon.Endpoint,
  http: [port: {:system, "PORT"}],
  url: [scheme: "http", host: "kappamon.com", port: 80],
  server: true,
  root: ".",
  version: Mix.Project.config[:version],
  cache_static_manifest: "priv/static/manifest.json"

nginx.conf:

server {
  listen 80;
  server_name kappamon.com;
}

domains:

kappamon.com

My DNS service provider is Namecheap so I have the following configuration

and so I just get the Nginx welcome page

Another weird thing is that the original domain kappa.apitome.ca is working perfectly fine but kappamon.com is not working.

Hi,

I'm new to Elixir and Phoenix. Been trying to deploy to DO and can't get past this point. I've see Issue #39 which sounds like my issue even though I'm using v1.1.1. The tar.gz file is being created in the rel folder rather than in the _build folder.

I get the following message:

...
Generated paul app
==> Assembling release..
==> Building release paul:0.0.1 using environment prod
==> Including ERTS 8.3 from /usr/lib/erlang/erts-8.3
==> Packaging release..
==> Release successfully built!
    You can run it in one of the following ways:
      Interactive: rel/paul/bin/paul console
      Foreground: rel/paul/bin/paul foreground
      Daemon: rel/paul/bin/paul start
** (File.CopyError) could not copy from "/home/deploy/paul/_build/prod/rel/paul/releases/0.0.1/paul.tar.gz" to "/home/deploy/deployments/paul/paul.tar.gz": no such file or directory
    (elixir) lib/file.ex:524: File.cp!/3
    lib/gatling/tasks/deploy.ex:109: Mix.Tasks.Gatling.Deploy.copy_release_to_deploy/1
    lib/gatling/tasks/deploy.ex:201: Mix.Tasks.Gatling.Deploy.call/2
    lib/gatling/tasks/deploy.ex:35: Mix.Tasks.Gatling.Deploy.deploy/1
    (mix) lib/mix/task.ex:300: Mix.Task.run_task/3
    (mix) lib/mix/cli.ex:58: Mix.CLI.run_task/2

rel/config.exs:

use Mix.Releases.Config,
    # This sets the default release built by `mix release`
    default_release: :default,
    # This sets the default environment used by `mix release`
    default_environment: :dev

# For a full list of config options for both releases
# and environments, visit https://hexdocs.pm/distillery/configuration.html


# You may define one or more environments in this file,
# an environment's settings will override those of a release
# when building in that environment, this combination of release
# and environment configuration is called a profile

environment :dev do
  set dev_mode: true
  set include_erts: false
  set cookie: :"X5y=yyPyygmAByM~iONz^Ti`|vyY7(m56.U_Y$w:eJTyDjYqZX$+vKNA?u3xvHV<"
end

environment :prod do
  set include_erts: true
  set include_src: false
  set cookie: :"X5y=yyPyygmAByM~iONz^Ti`|vyY7(m56.U_Y$w:eJTyDjYqZX$+vKNA?u3xvHV<"
end

# You may define one or more releases in this file.
# If you have not set a default release, or selected one
# when running `mix release`, the first release in the file
# will be used by default

release :paul do
  set version: current_version(:paul)
end

Elixir Version

elixir -v
Erlang/OTP 19 [erts-8.3] [source-d5c06c6] [64-bit] [async-threads:10] [hipe] [kernel-poll:false]

Elixir 1.4.4

Thank you for your help!

Best,
Paul

Looking at the PORT section of the Readme, it looks like this tool will work for a single phoenix app.
What about umbrella projects hosting multiple phoenix apps ?

This is quite a common requirement when your server provides APIs and an Admin for instance. As they share common data structures the umbrella project is a good solution.
In this case, there are several endpoints and thus several ports that can be then mapped to different nginx subdomains (port 4000 is www.domain.com, port 4001 is api.domain.com, port 4002 is admin.domain.com, ...).

In tasks the command such as mix phoenix.digest is for Phoenix 1.2.
I think it's time to add support for 1.3 version.

1. A new branch for 1.3 phx command (can 1.2 and 1.3 deploy together in same machine?)
2. Master branch, gatling check the project (mix file?) and choose the version of command
3. Master branch, gatling check an environment file and choose the version of command
   I current think 2 may be the solution.

I've tried a lot of time deploying an umbrella project on Digital Ocean with gatling.

• The first deploy is working fine (generates version 0.0.1)
• Then I update something, changing version in mix.exs to be "0.0.2" (which is > than 0.0.1)and It's all right, with a nice "hot upgrade too"
• Then I'll go thorugh the third release (0.0.3) and I always get this error:

**"Failed to build release: remote: Missing .rel for iamviolet:0.0.2 at _build/prod/rel/iamviolet/releases/0.0.2/iamviolet.rel "**

It seems like upgrading is not going to generate a .rel file.
Note: the release 0.0.3 is generated but not used as permanent.

What I'm doing wrong?

Distillery Version: 1.1.2
Gatling version: 1.1.1

When git push production master and then visit url, it shows

function Phoenix.LiveReloader.call/2 is undefined (module Phoenix.LiveReloader is not available)

seems it uses phoenix_live_reload module which is only for dev.

remote: $ mix release --upgrade --upfrom=0.0.1479980159 --warnings-as-errors --env=prod (/root/starsoul)
remote: ==> Assembling release..
remote: ==> Building release starsoul:0.0.1479988632 using environment prod
remote: ==> Including ERTS 8.1 from /usr/lib/erlang/erts-8.1
remote: ==> Generated .appup for starsoul 0.0.1479980159 -> 0.0.1479988632
remote: ==> Relup successfully created
remote: ==> Packaging release..
remote: ==> Release successfully built!
remote:     You can run it in one of the following ways:
remote:       Interactive: rel/starsoul/bin/starsoul console
remote:       Foreground: rel/starsoul/bin/starsoul foreground
remote:       Daemon: rel/starsoul/bin/starsoul start
remote: $ service starsoul upgrade 0.0.1479988632
remote: Release 0.0.1479988632 not found, attempting to unpack releases/0.0.1479988632/starsoul.tar.gz
remote: Unpacked successfully: "0.0.1479988632"
remote: Installed Release: 0.0.1479988632
remote: Made release permanent: "0.0.1479988632"
To [email protected]:starsoul
   3154393..723ea37  master -> master

How to solve this problem? Where did I miss? Thanks a lot!

Hey guys, great project!

I would recommend you target Distillery instead of Exrm at this point, is there anything I can do to help?

Request a Gatling task like mix gatling.unload proj_name to completely delete deploy.
Might include

1. Stopping the erlang node/process
2. Delete git folder and deployments/proj_name
3. Delete nginx conf
   So, for testing, don't need to manually do these things.

I have my endpoint config set up as described in the README. When I attempt a deploy, I get an error that the port is nil:

The database for Tracker.Repo has already been created

01:18:12.463 [info]  Already up
01:18:12.600 [info] Application tracker exited: Tracker.start(:normal, []) returned an error: shutdown: failed to start child: Tracker.Endpoint
    ** (EXIT) shutdown: failed to start child: Phoenix.Endpoint.Server
        ** (EXIT) an exception was raised:
            ** (RuntimeError) server can't start because :port in config is nil, please use a valid port number
                (phoenix) lib/phoenix/endpoint/server.ex:31: Phoenix.Endpoint.Server.to_port/1
                (phoenix) lib/phoenix/endpoint/server.ex:28: Phoenix.Endpoint.Server.default/3
                (phoenix) lib/supervisor.ex:17: anonymous fn/5 in Phoenix.Endpoint.Server.init/1
                (elixir) lib/enum.ex:1755: Enum."-reduce/3-lists^foldl/2-0-"/3
                (phoenix) lib/supervisor.ex:15: Phoenix.Endpoint.Server.init/1
                (stdlib) supervisor.erl:294: :supervisor.init/1
                (stdlib) gen_server.erl:328: :gen_server.init_it/6
                (stdlib) proc_lib.erl:247: :proc_lib.init_p_do_apply/3

Since the only thing the docs say about the port setting is "Gatling will set this for you automatically" I'm not sure what to look at next. Thanks or any help.

Environment: DigitalOcean server Ubuntu 16.04, nothing else on it but elixir, nginx, and postgresql. I followed the instructions in this blog post as closely as possible.

After upgrading to Gatling 1.0, when I try to run sudo mix gatling.deploy my_project, I get this error:

/etc/init.d/my_project: 16: /etc/init.d/my_project: /home/ubuntu/deployments/my_project/bin/my_project: not found

I suspect this is due to the the path defined here:

Is this problem specific to the new release?

I'm deploying on AWS EC2 (Ubuntu 16.04)

Following the README at the point where I'm told to git remote add production git@<address.to.server>:<project_name>.git where should this git user come from and why is the directory .git?

If I try to follow this guide that doesn't work at all. What works though (as you would expect) is using git remote add production <username_user_before>@<address.to.server>:<project_name>.

Am I missing something?

Use git init --bare instead of a normal git init with denyCurrentBranch=updateInstead

User adds a file to the root of their project named ./nginx.conf

On a deploy:

If nginx.conf

• Validate the config file. Exit if invalid.
• Copy the nginx file to /etc/nginx/sites-available/ if different

It's all but there apart from the update-rc steps and a few extra setup steps, like git v2 + install.

This is a note for myself to get stuck in as much as anything. Once I'm past my current project, I'll circle back to this. As I use CentminMod which gives a nice setup on CentOS. I swapped from ubuntu servers a few years back too; timing is everything.

Anyone else needing/wanting/using CentOS?

Hi. From what I've gathered, the default behaviour of running this guide is that the elixir app will be running as the root user. Am I missing something? If not, what steps can I take so that the app process runs as other user, like deploy?

Thanks!

I deployed my app to Digital Ocean and Gatling selected port 49615 for it. But DO gave error 502 for this configuration, app started working only after I manually changed port to 4001 in init.d and nginx/sites-available configurations. May be there is some bug in detecting ports.

I've diagnosed at least part of the problems I'm having. This commit is the culprit: 64b6d68#diff-e6f9464d10bcc3e75cbf33de35289e38R50

This commit adds the creation of deploy_dir during "mix gatling.load".
But the receive action checks for the presence of deploy_dir, and if the directory is present attempts an upgrade, as seen here: https://github.com/hashrocket/gatling/blob/v1.1.0/lib/gatling/tasks/receive.ex#L17-L19

That upgrade action fails on first push because of course there is no previous release to upgrade. You can see this in the console records I posted to #38.

This can be worked around just by rm -rf /home/deploy/deployment between mix gatling.load <myapp> and the initial push of the repository, which will allow the push to proceed normally and allow mix gatling.deploy to succeed without error.

I am closing #38 since this appears to be the root cause. However, I still run in to #39 on subsequent updates, so I'll leave that ticket open.

I was able to get gatling setup with little fuss (which is sweet!) but being new to Erlang, Elxir, and Phoenix I'm at a little bit of a loss for how to perform some administrative tasks on the server.

I think it'd be useful for people like me to know the how to run the Phoenix equivalents of the Rails world's:

• tail -f log/production.log
• rails console
• rails runner "Model.long_running_command"

I'm digging around and will be happy to submit a PR to the docs once I figure this out, but some best practice guidance would be appreciated!

I'm experimenting with a clean-ish umbrella app. Two apps, the core ( domain & db ) and a phoenix web app. A straight up initial deploy works fine and pushing produces suitable log noise to the effect it's released successfully and unpacked, made the 'release' permanent.

I'm using the git log version number in the umbrella project. The apps are fixed at 0.0.1 etc.
If I do a html change for example then push all as expected, log below. At this point, refreshing the app, there is no change. If I issue a /etc/init.d/briskoda_platform stop and start it loads, but still the old code.

This is the tail of the output:

remote: $ mix release --upgrade --upfrom=0.0.1484065140 --warnings-as-errors --env=prod (/home/colin/briskoda_platform)
remote: ==> Assembling release..
remote: ==> Building release briskoda_platform:0.0.1484065756 using environment prod
remote: ==> Including ERTS 8.2 from /usr/lib/erlang/erts-8.2
remote: ==> Relup successfully created
remote: ==> Packaging release..
remote: ==> Release successfully built!
remote:     You can run it in one of the following ways:
remote:       Interactive: rel/briskoda_platform/bin/briskoda_platform console
remote:       Foreground: rel/briskoda_platform/bin/briskoda_platform foreground
remote:       Daemon: rel/briskoda_platform/bin/briskoda_platform start
remote: $ mix ecto.migrate (/home/colin/briskoda_platform/apps/briskoda)
remote: 
remote: 16:29:54.274 [info]  Already up
remote: $ service briskoda_platform upgrade 0.0.1484065756
remote: Release 0.0.1484065756 not found, attempting to unpack releases/0.0.1484065756/briskoda_platform.tar.gz
remote: Unpacked successfully: "0.0.1484065756"
remote: Release 0.0.1484065756 is already unpacked, now installing.
remote: Installed Release: 0.0.1484065756
remote: Made release permanent: "0.0.1484065756"

Looks good.

If I touch the individual apps mix.exs to be 0.0.1 > 0.0.2 I get the appropriate appup file but again no hot reload.

remote: ==> Including ERTS 8.2 from /usr/lib/erlang/erts-8.2
remote: ==> Generated .appup for briskoda 0.0.1 -> 0.0.2
remote: ==> Generated .appup for briskoda_web 0.0.1 -> 0.0.2
remote: ==> Relup successfully created
remote: ==> Packaging release..
remote: ==> Release successfully built!
remote:     You can run it in one of the following ways:
remote:       Interactive: rel/briskoda_platform/bin/briskoda_platform console
remote:       Foreground: rel/briskoda_platform/bin/briskoda_platform foreground
remote:       Daemon: rel/briskoda_platform/bin/briskoda_platform start
remote: $ mix ecto.migrate (/home/colin/briskoda_platform/apps/briskoda)

At this point a manual stop and start works, the new code boots.

At this point having gone over things; issues here; issues on distillery; code etc, I'm at a loss for what I've missed. This is the greatest clue but those steps are covered of by the gatling process.
mix release --upgrade --upfrom=0.0.1484065140 --warnings-as-errors --env=prod

Anyone else got a simple umbrella app hot reloading?

When doing git push for the first time, I was seeing this error:

fatal: bad numeric config value 'updateInstead' for 'receive.denycurrentbranch' in config: invalid unit
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

After googling around for a while I realized this was because my git version was too old for this git config value. Debian 8 had decided to install git 2.1.4. I had to use a testing repo to get the latest git version 2.11.0:

1. Added deb http://ftp.us.debian.org/debian testing main contrib non-free to /etc/apt/sources.list
2. apt-get update
3. apt-get install git/testing

I thought I would let you guys know and if someone is searching for this error they may find this. Perhaps the minimum versions could get a special callout in the README?

When I push to production master, always need to git checkout -- mix.lock

local: Working directory has unstaged changes.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

	modified:   mix.lock

Should I add mix.lock into .gitignore?
How does the .lock file change after deploy? (I assume the dev and prod .lock should be same?)
Am I missing something, Thanks!

When I run MIX_ENV=prod sudo --preserve-env mix gatling.deploy my_app I get this error:

** (FunctionClauseError) no function clause matching in IO.chardata_to_string/1

The following arguments were given to IO.chardata_to_string/1:

    # 1
    nil

(elixir) lib/io.ex:445: IO.chardata_to_string/1
(elixir) lib/path.ex:500: Path.do_join/3
(elixir) lib/path.ex:495: Path.join/2
(elixir) lib/path.ex:472: Path.join/1
lib/gatling/gatling.ex:19: Gatling.env/2
lib/gatling/tasks/deploy.ex:28: Mix.Tasks.Gatling.Deploy.deploy/1
(mix) lib/mix/task.ex:301: Mix.Task.run_task/3
(mix) lib/mix/cli.ex:75: Mix.CLI.run_task/2

I have a elixir cluster project with one phoenix app inside it. This is on Ubuntu 16.04 LTS. I can compile the project in production mode on local computer.

I'm using the below command on my VPS to deploy an app I recently put together.
sudo -E mix gatling.deploy kegcopr_api

However, the deployment errors out when it tries to start the app as a service.

$ mix release --warnings-as-errors --env=prod (/home/deploy/kegcopr_api)
==> Assembling release..
==> Building release kegcopr_api:0.0.1 using environment prod
==> Including ERTS 8.3 from /home/deploy/.asdf/installs/erlang/19.3/lib/erlang/erts-8.3
==> Packaging release..
==> Release successfully built!
    You can run it in one of the following ways:
      Interactive: _build/prod/rel/kegcopr_api/bin/kegcopr_api console
      Foreground: _build/prod/rel/kegcopr_api/bin/kegcopr_api foreground
      Daemon: _build/prod/rel/kegcopr_api/bin/kegcopr_api start
$ tar -xf kegcopr_api.tar.gz (/home/deploy/deployments/kegcopr_api)
/etc/init.d/kegcopr_api already exists
$ service kegcopr_api start
** (ErlangError) erlang error: :enoent
    (elixir) lib/system.ex:564: System.cmd("service", ["kegcopr_api", "start"], [stderr_to_stdout: true, into: %IO.Stream{device: :standard_io, line_or_bytes: :line, raw: false}])
    lib/gatling/tasks/deploy.ex:189: Mix.Tasks.Gatling.Deploy.start_service/1
    lib/gatling/tasks/deploy.ex:201: Mix.Tasks.Gatling.Deploy.call/2
    lib/gatling/tasks/deploy.ex:39: Mix.Tasks.Gatling.Deploy.deploy/1
    (mix) lib/mix/task.ex:294: Mix.Task.run_task/3
    (mix) lib/mix/cli.ex:58: Mix.CLI.run_task/2

Any help related to this issue would greatly be appreciated.

And I forgot to mention I'm using erlang 19.3 and elixir 1.4.2 via the asdf package manager.

Update
Removed the file /etc/init.d/kegcopr_api and reran the below command,
sudo -E mix gatling.deploy kegcopr_api

Now I'm getting the following error messages.

$ mix release --warnings-as-errors --env=prod (/home/deploy/kegcopr_api)
==> Assembling release..
==> Building release kegcopr_api:0.0.1 using environment prod
==> Including ERTS 8.3 from /home/deploy/.asdf/installs/erlang/19.3/lib/erlang/erts-8.3
==> Packaging release..
==> Release successfully built!
    You can run it in one of the following ways:
      Interactive: _build/prod/rel/kegcopr_api/bin/kegcopr_api console
      Foreground: _build/prod/rel/kegcopr_api/bin/kegcopr_api foreground
      Daemon: _build/prod/rel/kegcopr_api/bin/kegcopr_api start
$ tar -xf kegcopr_api.tar.gz (/home/deploy/deployments/kegcopr_api)
$ update-rc.d kegcopr_api defaults
** (ErlangError) erlang error: :enoent
    (elixir) lib/system.ex:564: System.cmd("update-rc.d", ["kegcopr_api", "defaults"], [stderr_to_stdout: true, into: %IO.Stream{device: :standard_io, line_or_bytes: :line, raw: false}])
    lib/gatling/tasks/deploy.ex:139: Mix.Tasks.Gatling.Deploy.install_init_script/1
    lib/gatling/tasks/deploy.ex:201: Mix.Tasks.Gatling.Deploy.call/2
    lib/gatling/tasks/deploy.ex:37: Mix.Tasks.Gatling.Deploy.deploy/1
    (mix) lib/mix/task.ex:294: Mix.Task.run_task/3
    (mix) lib/mix/cli.ex:58: Mix.CLI.run_task/2

Similar to `mix phx.digest.clean (https://hexdocs.pm/phoenix/Mix.Tasks.Phx.Digest.Clean.html)

Can specify --age (keep releases within a specific period) or --n (keep n most recent releases)

I keep getting permission error when try to run mix.gatling deploy <project.name> in the server (Ubuntu 16.04).

Should I run the command using sudo?

I'm trying to deploy an app for the first time, and I've been following the instructions in the readme, but when I run sudo mix gatling.deploy hello_phoenix

I get this error:

==> Assembling release..
==> Building release hello_phoenix:0.0.1 using environment prod
==> Including ERTS 8.2 from /usr/lib/erlang/erts-8.2
==> Packaging release..
==> Release successfully built!
    You can run it in one of the following ways:
      Interactive: _build/prod/rel/hello_phoenix/bin/hello_phoenix console
      Foreground: _build/prod/rel/hello_phoenix/bin/hello_phoenix foreground
      Daemon: _build/prod/rel/hello_phoenix/bin/hello_phoenix start
** (File.CopyError) could not copy from "/home/seth/hello_phoenix/rel/hello_phoenix/releases/0.0.1/hello_phoenix.tar.gz" to "/home/seth/deployments/hello_phoenix/hello_phoenix.tar.gz": no such file or directory
    (elixir) lib/file.ex:524: File.cp!/3
    lib/gatling/tasks/deploy.ex:110: Mix.Tasks.Gatling.Deploy.copy_release_to_deploy/1
    lib/gatling/tasks/deploy.ex:201: Mix.Tasks.Gatling.Deploy.call/2
    lib/gatling/tasks/deploy.ex:35: Mix.Tasks.Gatling.Deploy.deploy/1
    (mix) lib/mix/task.ex:294: Mix.Task.run_task/3
    (mix) lib/mix/cli.ex:58: Mix.CLI.run_task/2

Note, the file it's looking for exists in ~/hello_phoenix/_build/prod/rel/hello_phoenix/releases/0.0.1
but it's looking in ~/hello_phoenix/rel instead.

Any idea why? How do I fix this?

Gatling is facinating! But following the docs will come up to some problems:

1. Server Prerequisites
   git version must greater than 2.0
   Install Node (using nvm)
   Install Brunch gloabally, npm install -g brunch

2. Necessary Config Files
   ./rel/config.exs
config/prod.secret.exs
domains
deploy.exs -> deploy build static assets
   upgrade.exs -> upgrade build static assets

3. How to setup SSL
   Using Lets Encrypt

4. Trouble shooting

This line fails if the .env file does not exist:

It's not clear what the format of the .env file is, and it is not created automatically.

Anyway, that line makes the init script print out a lot of output before the pong, making the upgrade test fail.

$ sudo service <app> ping
cat: /home/deploy/deployments/<app>/.env: No such file or directory
export HOME='/home/deploy/deployments/<app>'
export LANG='en_US.UTF-8'
export LANGUAGE='en_US.UTF-8'
export LC_ADDRESS=''
export LC_ALL='en_US.UTF-8'
export LC_COLLATE=''
export LC_CTYPE='UTF-8'
export LC_IDENTIFICATION=''
export LC_MEASUREMENT=''
export LC_MESSAGES=''
export LC_MONETARY=''
export LC_NAME=''
export LC_NUMERIC=''
export LC_PAPER=''
export LC_TELEPHONE=''
export LC_TIME=''
export MIX_ENV='prod'
export PATH='/home/deploy/.asdf/bin:/home/deploy/.asdf/shims:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games'
export PORT='50425'
export PWD='/'
export TERM='screen'
pong

I've been trying to upgrade my app recently and it kept giving me no_matching_releup errors and no matter what i did, it would always automatically use --upfrom=0.0.9 but I just figured out why it's doing that.

The culprit is this code:

  def mix_release(env) do
    last_release = List.last(env.releases)
    bash("mix", ~w[release --upgrade --upfrom=#{last_release} --warnings-as-errors --env=prod], cd: env.build_dir)
    env
  end

In particular, the List.last(env.releases) part.

env.releases is a list of strings and that means "0.0.9" ends up at the end of the list rather than newer releases like "0.0.10" or "0.0.11"

Here's the output from my env.releases:

["0.0.1", "0.0.10", "0.0.11", "0.0.12", "0.0.2", "0.0.4", "0.0.5", "0.0.6",
 "0.0.7", "0.0.8", "0.0.9"]

Since it keeps using 0.0.9 I can't actually upgrade past that unless I increment other parts of the version number, which I'm not ready to do.

First off: Thanks for this project, it looks very promising!

I'm currently having trouble setting up everything as the gatling.deploy task fails when trying to copy_release_to_deploy. I am using a minimal Distillery config and haven't changed the output_dir.
Its default is _build/<$MIX_ENV>/rel/<release_name> and that's where my build is going when I invoke gatling.deploy.

However, the built_release_path default is in the rel directory (as opposed to _build) – this leads to the copy_release_to_deploy step failing, as it expects the build in rel/...

What am I doing wrong here? I think I could just add a Distillery config for that, but it doesn't seem like the proper way – that's why I'm asking. Thanks again!

Hi!! Thanks so much for building gatling, I was struggling to push my mix project with nginx to a ubuntu VPS server, and gatling just takes care of it, maybe it's not the best for real deployments, but so cool for fast prototyping on a server (which I was after)

I'm wondering if anyone is using gatling with CI/CD, I've found Gitlab CI has documented how to run their service with Elixir/Phoenix apps, but not sure how gatling would adapt to that