-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add stacks-userguide.md #391
Conversation
21bb261
to
e8ac469
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Excellent!
-name: myexternalname | ||
publish_port: 3001 | ||
internal_port: 3000 | ||
``` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
curious why we're using publish_port
and internal_port
? why not use a more docker standard syntax internal_port:external_port
such as:
myservice1:
image: appcelerator/pinger:latest
public:
- name: myexternalname
ports: 3000:3001
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Protocol could be handled the same way as 3000:3001/udp
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jhaynie We did a lot of debating over it initially because in this case, publish_port
is not for exposing the container port on a node host port. Instead, it takes the service port (used to access the service internally within the stack network) and publishes it via the reverse proxy, mapping it as desired, for external use. The debate was over using a format that was familiar vs. confusing people with the different intention since HOST:CONTAINER
mapping already has a well-established in Docker. However, that argument did go out the window when we decided to use that format for amp service create
anyway, so we definitely should revisit this. The format we use for amp service create
, is more powerful; it even supports specifying a name, so for example: admin:3000
will map the service port to admin
via haproxy.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah ok that makes a lot of sense.
Add "stacks-userguide.md" to docs
Summary:
Test: read-it :)