| commit | 38aae0fdc88450069c4d0a7a250759a8f057b6fd | [log] [tgz] |
|---|---|---|
| author | Sameer Brenn <sbrenn@twitter.com> | Fri Apr 20 13:26:08 2018 -0700 |
| committer | Santhosh Kumar <sshanmugham@twitter.com> | Fri Apr 20 13:26:08 2018 -0700 |
| tree | 1b793e77d787a73e75c98a7bda02f110837f4b5f | |
| parent | ad0bc5f9df4bcb6c5713db6d2defdffed006210c [diff] |
Add --pid-file flag to `aurora task ssh` to write the PID of the underlying SSH command to a specified file. My team has some scripts to start devel shards which create tunnels: ``` aurora task ssh -L 8002:http --ssh-options "-f -N" "$DC/$USER/devel/proxyapp/0" aurora task ssh -L 9002:health --ssh-options "-f -N" "$DC/$USER/devel/proxyapp/0" ``` We use fixed local port numbers because that way we can run dependent services locally that look for locally-running copies of the same service on a fixed port, but then those requests get tunnelled through to the devel shard. When the devel shard is restarted, however, the tunnel is still running so the subsequent call to create a new tunnel fails because it can't bind to the fixed port. If we save the SSH process PID to a file, we can then kill existing tunnel to the old instance before starting up the new tunnel to the new instance. Testing Done: ``` $ ./pants test src/test/python/apache/aurora/client:: ``` And when applying the same patch to our local repo at Twitter: ``` $ ./pants run twitter/src/main/python/twitter/aurora/client/cli_internal:aurora_internal -- task ssh -L 8005:http --ssh-options "-n -N" --pid-file /tmp/p "smf1/sbrenn/devel/proxyapp/0" & $ ps -p `cat /tmp/p` PID TTY TIME CMD 34729 ttys000 0:00.05 ssh -t -n -N -L 8005:smf1-aki-27-sr1.prod.twitter.com:31794 sbrenn@smf1-aki-27-sr1.prod.twitter.com cd /var/lib/mesos/slaves/*/frameworks/*/exec ``` Reviewed at https://reviews.apache.org/r/66697/
Apache Aurora lets you use an Apache Mesos cluster as a private cloud. It supports running long-running services, cron jobs, and ad-hoc jobs. Aurora aims to make it extremely quick and easy to take a built application and run it on machines in a cluster, with an emphasis on reliability. It provides basic operations to manage services running in a cluster, such as rolling upgrades.
To very concisely describe Aurora, it is like a distributed monit or distributed supervisord that you can instruct to do things like run 100 of these, somewhere, forever.
Aurora is built for users and operators.
User-facing Features:
Under the hood, to help you rest easy:
Aurora can take over for most uses of software like monit and chef. Aurora can manage applications, while these tools are still useful to manage Aurora and Mesos themselves.
However, if you have very specific scheduling requirements, or are building a system that looks like a scheduler itself, you may want to explore developing your own framework.
Are you using Aurora too? Let us know, or submit a patch to join the list!
If you have questions that aren‘t answered in our documentation, you can reach out to one of our mailing lists. We’re also often available in IRC: #aurora on irc.freenode.net.
You can also file bugs/issues in our JIRA queue.
Except as otherwise noted this software is licensed under the Apache License, Version 2.0
Licensed 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.