3 ms·

> It is still nice for quickly running something and get rid of it. For instance an ad-hoc script mocking an API endpoint that you can run on an arbitrary port

> It is still nice for quickly running something and get rid of it. For instance an ad-hoc script mocking an API endpoint that you can run on an arbitrary port in seconds. That is one of the many things Docker and Docker Compose are good at. If you have a docker-compose.yml file you can do just that with any web server backend.

hrktb 6y ago
Say you wrote your 10 lines script that mocks your third party endpoint. running it on port 7659 is > php -S 0.0.0.0:7659 scripts/test.php and done. Compared to this one liner, the proposition is making a dockerfile with a base image, perhaps your local extensions if you had to compile them, and configuration if you changed from the default one. Then a docker-compose to share your local file, which references the previous Dockerfile, and specifies the right port. Knowing if your testfile is not self contained, you’d need to map any services it needs to access to. Then you run the whole. It is by no mean complicated, and you could keep around a template of all of that around in case you need it (or you copy it from your main application’s docker files, and modify if you need to it more lax). As you say it also gives you more freedom. It’s just a tad more tedious than literally one line.
- paledot 6y ago
  That's a fair use case, although I might still wrap that one-liner in a Docker container because the service consuming the mock is probably Dockerized. But indeed it doesn't make sense to configure and run another nginx container just for that 10-line mock.
cringepirate 6y ago
Writing a quick script that deals with a HTTP request is much simpler than having to muck around with docker. Also not everyone cares for docker. I find docker and a lot of these container technologies just add more complexity and don't add any value.

3 ms·

> It is still nice for quickly running something and get rid of it. For instance an ad-hoc script mocking an API endpoint that you can run on an arbitrary port

by chromedev 6y ago

hrktb 6y ago
Say you wrote your 10 lines script that mocks your third party endpoint. running it on port 7659 is > php -S 0.0.0.0:7659 scripts/test.php and done. Compared to this one liner, the proposition is making a dockerfile with a base image, perhaps your local extensions if you had to compile them, and configuration if you changed from the default one. Then a docker-compose to share your local file, which references the previous Dockerfile, and specifies the right port. Knowing if your testfile is not self contained, you’d need to map any services it needs to access to. Then you run the whole. It is by no mean complicated, and you could keep around a template of all of that around in case you need it (or you copy it from your main application’s docker files, and modify if you need to it more lax). As you say it also gives you more freedom. It’s just a tad more tedious than literally one line.
- paledot 6y ago
  That's a fair use case, although I might still wrap that one-liner in a Docker container because the service consuming the mock is probably Dockerized. But indeed it doesn't make sense to configure and run another nginx container just for that 10-line mock.
cringepirate 6y ago
Writing a quick script that deals with a HTTP request is much simpler than having to muck around with docker. Also not everyone cares for docker. I find docker and a lot of these container technologies just add more complexity and don't add any value.