Skip to content
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 Memcached service configuration file and documentation. #927

Merged
merged 5 commits into from
Aug 2, 2018

Conversation

jeffsheltren
Copy link
Contributor

The Problem/Issue/Bug:

Currently ddev does not provide a Memcached container. Memcached is used as a caching layer by many applications.

How this PR Solves The Problem:

Adds an example docker-compose file and documentation to setup a Memcached container within a ddev environment.

Manual Testing Instructions:

Follow instructions in documentation included in PR to create a Memcached container.

Automated Testing Overview:

This should get picked up automatically by the already-existing servicetest test script.

Related Issue Link(s):

#269

Copy link
Member

@rfay rfay left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wow, thanks! This worked absolutely great out of the box for me.

  • I think the environment stanza should go away.
  • This needs a test. TestServices wants to test it, but didn't foresee a service without an http interface, so it doesn't actually test it.

If you want to give a shot at a test, that would be fantastic, otherwise we'll try to add one in next release cycle if you're OK with us pushing into your PR.

Without a test, the example file runs the risk of becoming obsolete with future changes to ddev, causing infinite pain to users.

Thanks for this!

com.ddev.site-name: ${DDEV_SITENAME}
com.ddev.approot: $DDEV_APPROOT
com.ddev.app-url: $DDEV_URL
environment:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm pretty sure the entire environment stanza is not useful; we don't support access via http on named project via port 11211 because 11211 is a tcp interface, not http. So ddev-router is not involved at all. (I tested and it works fine without this section)

labels:
# These labels ensure this service is discoverable by ddev
com.ddev.site-name: ${DDEV_SITENAME}
com.ddev.approot: $DDEV_APPROOT
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The "labels" section is also not useful since site-name, app-root, and app-url aren't used here. The commend about "Discoverable by ddev" is incorrect, I think, I know it's from the example.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops, I was wrong about this. com.ddev-site-name is absolutely required, it's what is used by ddev rm and ddev stop to take down the container. The other two don't seem to be useful. (Noticed a spare memcached container hanging around on my host!)


command: ["-m", "128"]

# This links the memcached service to the web service defined in the main docker-compose.yml, allowing applications running in the web service to access the memcached service at memcached:11211
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The 'web' stanza is also not useful. Pretty sure it should be removed.

@rfay
Copy link
Member

rfay commented Jul 13, 2018

Hoping to get this in before it's too stale, know you're busy. Would love to have a rebase of it and get it going again. I don't think it will take too much to get it in. Let us know if you want us to run with it instead (and you don't mind commits being pushed into your fork).

@rfay rfay added this to the v1.1.0 milestone Jul 14, 2018
@rfay
Copy link
Member

rfay commented Jul 14, 2018

Moving to v1.1.0

@jeffsheltren
Copy link
Contributor Author

Thanks for the feedback @rfay! I believe I addressed everything in the docker-compose file with the commit today. I'd love your help with adding a test for it. I believe we can simply test a TCP connection to port 11211, but I'm not sure how to do so. Feel free to push to my fork if that's easiest.

@rfay
Copy link
Member

rfay commented Jul 18, 2018

Could you rebase this? Or mind if I rebase and push back into your fork?

@rfay
Copy link
Member

rfay commented Jul 31, 2018

@jeffsheltren Could you please click the checkbox that allows collaborators to push into this, or grant me access to your fork? Was just trying to rebase and push to get the last test fail out of there (which had nothing to do with this of course)

Copy link
Contributor

@andrewfrench andrewfrench left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've updated the tests to not assume HTTP interaction and got the memcached service responding to TCP connections. This requires a bit more configuration in the test itself to define the expected protocol, private port, and interaction path (as the HTTP test was returning HTTP301 at /, not 200).

Aside from my changes, the additions here look good to me and I was able to get the service up and running with the new docker-compose file and docs.

Copy link
Member

@rfay rfay left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, I'm impressed how fast you turned this around! I do think we should try to access the correct port from within the web container.

Also, it only looks for tcp/http connectivity, it would be lovely if it did something to see that the daemon listening is the right one and actually responds correctly to some URI (or tcp command for memcached).


for _, port := range container.Ports {
if port.PrivatePort == targetPort && port.PublicPort != 0 {
address := fmt.Sprintf("http://127.0.0.1:%d%s", port.PublicPort, path)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a decent test, but I think it may be leaving out the important fact that we have to be able to access the port from within the web container. I imagine this approach is what we were doing before, but we should consider using app.Exec() to take an action within the web container. nc (netcat) is installed in there, it would do fine I think.


for _, port := range container.Ports {
if port.PrivatePort == targetPort {
address := fmt.Sprintf("127.0.0.1:%d%s", port.PublicPort, path)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As with the other one, this tests from the host's perspective, but may not be an adequately valid test because it's not testing from the web container's perspective.

@andrewfrench andrewfrench self-assigned this Aug 1, 2018
Copy link
Member

@rfay rfay left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks to both of you for this. Thanks for the more-realistic testing scenario @andrewfrench . This should be ready to go.

Copy link
Contributor

@rickmanelius rickmanelius left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me. I was able to add the yaml file and see it pull down and stand up. I'm not as familiar with the actual testing of memcached, so if Randy and Andrew were able to successfully interact with it, I'm good with that!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants