Comments (8)
@Gnep Sure thing!
First, a little background. Cog can currently deal with two types of command bundles: "native" and Docker.
With "native" bundles, the commands are executed directly on the Relay's host. Furthermore, you (as the operator of the Cog infrastructure) are responsible for installing the necessary binaries on the Relay.
In contrast, Docker command bundles are packaged up as Docker images. As they are invoked, Relay will execute the commands in a container, and not directly on the host. Additionally, the Relay takes care of "installing" the bundle for you; it just pulls it down from whatever Docker repository it is pointed at. This makes dealing with Docker-based command bundles very easy. For both types of bundles, you need to upload a metadata file to the Cog server to make Cog aware of the bundle, but with Docker bundles, that's all you need to do. Native bundles require additional installation steps. That means additional configuration management you'll need to deal with; it also complicates things like upgrading bundles in Cog, which is otherwise very simple.
As a result, the overwhelming majority (all?) the bundles you're likely to find in the wild, including the ones on https://bundles.operable.io are going to be Docker bundles, because they're so much easier to deal with.
And so, to get back to the question you asked, Relay interacts with the Docker engine directly by using docker.sock
. I think we tried some other ways, but this is the most efficient. It would be possible run Relay without Docker support by setting the RELAY_ENABLED_ENGINES setting to native
(instead of the default of native,docker
), but they you can only use the native bundles, which limits your options quite a bit, IMHO.
from cog.
@Gnep It doesn't sound like Hyper.sh is a good fit for Relay at the moment. In addition to the need for docker.sock
access, Relay also does some intelligent caching of containers to cut down startup time for frequently-executed commands, which really cuts down execution time in complex command pipelines.
I don't see a quick fix or workaround for this, and it seems like it would take a non-trivial amount of work to support this deployment model. I'm not saying that it's impossible, necessarily, just that it would take some doing.
(Additionally, trying to use "native" bundles instead by packaging the command executables up with a Relay executable (so everything is in one container and nothing additional needs to be scheduled) won't work either, because Cog isn't currently designed to have Relays come and go that way.)
from cog.
Do you mind pasting the content of docker-compose.override.slack.yml
(or s/slack/hipchat/
) with credentials retracted? There's this ENV VAR that needs being set in both the Cog and the Relay containers: RELAY_COG_TOKEN
.
from cog.
Hi Tu,
11:28:07 [Gnep@Pi cog]$ cat docker-compose.override.yml
version: '2'
services:
cog:
environment:
- COG_SLACK_ENABLED=1
- SLACK_API_TOKEN=${SLACK_API_TOKEN}
- COG_BOOTSTRAP_USERNAME=admin
- COG_BOOTSTRAP_PASSWORD=changeme
- COG_BOOTSTRAP_EMAIL_ADDRESS=cog@localhost
- COG_BOOTSTRAP_FIRST_NAME=Cog
- COG_BOOTSTRAP_LAST_NAME=Administrator
- RELAY_ID=00000000-0000-0000-0000-000000000000
- RELAY_COG_TOKEN=supersecret
relay:
environment:
- RELAY_ID=00000000-0000-0000-0000-000000000000
- RELAY_COG_TOKEN=supersecret
Pls note that I comment out two lines below in docker-compose.yml
:
privileged: true
volumes:
- /var/run/docker.sock:/var/run/docker.sock
- In Hyper, containers are fully privileged
- Hyper doesn't support docker.sock atm.
from cog.
@Gnep to my limited understanding, Cog needs access to docker.sock to schedule containers (a Cog chat command executes by using container). So whilst the error might have nothing to do with it, this might be the reason why you cannot pull the stack up successfully.
from cog.
@Gnep Yup, @rebyn is correct; if you're using Docker-based command bundles, Relay needs access to the Docker socket.
from cog.
Thanks @rebyn @christophermaier
Could you elaborate a bit what is the use of docker.sock by Relay?
from cog.
@christophermaier Thanks Chris.
Maybe I should change the question: as Cog runs commands using Docker format, does it make sense to support Hyper.sh as the backend engine?
AFAIK, Cog requires a server or a swarm cluster to run jobs. To keep a cluster running and manage it certainly introduces more cost and ops overhead. Hyper.sh is a container-native cloud, where you can launch containers on-demand, without the underlying cluster whatnot (not that we managed for you, there is just NO servers at all). And given the fast launch speed of containers, we provide a per-second billing model, e.g. your command runs for 10s, you pay for only that 10s.
What I imagine is that people run Cog server somewhere, and commands are executed in Hyper.sh in ad-hoc manner. In another word, serverless chatops.
What do you think?
from cog.
Related Issues (20)
- Cog crashes when new user registers (Slack) HOT 3
- Simplify Docker Image Build Process
- Break issues back out to their appropriate repositories HOT 1
- The "Cog Book" shows a security warning in Chrome and Firefox HOT 1
- Support shortdocs for cog commands HOT 2
- Add relay routing capabilities HOT 3
- operable:unique fails when value is empty HOT 2
- Updating Phoenix and Elixir
- Investigate HipChat integration test failures
- Cog Messages During Command Execution HOT 2
- Chat adapter for Discord HOT 1
- Using two different options causes a timeout
- Remove fork of Elixir-Slack
- Config values are sometimes not synced HOT 2
- The link to "Cog Public Slack Community" in the README is broken.
- Bundles Warehouse Link Dead HOT 1
- Commands removed from bundles still marked as ambiguous
- The project is abandoned? HOT 3
- https://book.cog.bot/ link does not work HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
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.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from cog.