envoyproxy / playground Goto Github PK

Currently assumes the image has been pulled already

render/getStatesetState issue i think

i reckon a jsonschema validation decorator can be created/used for the api validation

on the client its just a matter of fixing the react forms

Running with privileged and /var/run/docker.sock exposes root on the host

Running inside docker-in-docker limits this.

It still requires privileged but doesnt require the host docker socket - so doesnt expose root escalation directly.

This has some potential downsides/anti-patterns/features dep on pov

It would automatically stop all playground containers on exit of the playground container, eg.

Most of the ui is driven by events emitted from docker.

These could be output to a log widget so you can see eg containers starting/stopping, networks attaching etc

atm these are left behind.

these can be cleaned up as part of the container removal

The framework for react and aio/pytest testing has been added.

Tests have not yet...

This would make it really handy learning tool for envoy

Can you review javascript, python or docker code?

Want to help with documentation?

Contributions very welcome!!!

allow building from a dockerfile

if you change proxies and services the first set of changes gets deleted - some form foo

When you click on something twice quickly (eg removing a service/proxy etc) then it sends the remove signal twice

its quite handy that this isnt fixed right now as the api then throws unhandled docker errors, and this needs to be fixed first i think

The envoy proxy container is configured to allow streaming to a mounted volume

it would be great to hook up any files there and also the docker stream for a particular proxy to a logging window

would also be useful for services

yaml config is validated in requests before it reaches the api

it would be useful if it was also validated while the user typed (i guess with highlighting of errors would be ideal)

even better would be for Envoy config linting, which might be possible when Envoy has jsonschema dumps.

ref envoyproxy/envoy#13254 and envoyproxy/envoy#13233

for the service example, using aiohttp i think with http/s ws/s endpoints

this ~mostly works for networks, but with bugs

that can be auto loaded when creating a proxy

these are sent in the form, but not used in the container config yet

I have added half of the implementation for network aliasing already, altho im thinking its not an essential feature so im removing the current implementation for now.

It would be good to add this back - but it would be better to create a general network configuration ui for proxies and services rather than the current implementation

Start as we mean to go on 8/

atm if the ws disconnects it stops receiving messages

atm it doesnt pull the images need to add that

it would be good if you could download the files that you uploaded, or configurations you added

codecov had beatiful sunbursts!

This should a proxy for each port that is exposed - perhaps with color coded labels according to which proxy instance is exposing the port

currently networks get a prefix (and have it stripped etc)

containers need the same

Add some logic to mount custom services or override defaults

Add documentation

Currently when you remove a service (or perhaps several in quick succession) it receives an event update but when the ui goes to update the service list is out of sync

We might want to restrict what egress a service has and essentially force it route through envoy, if it wants/requires egress traffic

I think it should be doable from the docker side.

The main thing that would need to be added i think is a hidden network for envoy egress, or perhaps envoy would just need to be on a network allowing egress

however its implemented i can imagine quite a lot of reasons/ways that you would want to restrict egress traffic - esp from services

The python api could potentially be used separately for automated testing of setups/configurations

This would be quite a useful feature i think

Ideally this should be pluggable to different formats.

formats im thinking of are

• browser storage
• zipped docker-compose (ie envoy sandbox)
• github repo/dir - would require key setup if saving/exporting

the big issue is cerficates. Im thinking this is ok if we add a big warning not to expose real certs in playground configs (everywhere)

atm if something bad happens in api events or eg the socket is disconnected there is no way to notify user

That could issue certs etc

currently these are taken from the service definition.

these could be used as defaults, and the user could add/override

This would make the services much more extensible.

currently the creation/management of containers/networks etc is with docker, only

it would be great to add other backend container management engines

to ensure ordered consistency

Either/and/or per-instance or as runtime setting

When you edit a network it shows the create buttons

atm it starts listening to docker events only when the websocket is connected to.

this is fine for most events, but if the event is to cleanup the stale volumes/artifacts or other docker debris, then it is missed

the complexity here is that it needs to rem/forget the ws connection/s and publish to them - which would also make it work/better with multiple connections

in particular

• network/proxies
• network/services
• proxy/ports

so the grpc bridge can be tested out

currently the linting is just for files that happened to be touched as the test paths are hard coded

this needs the test paths to be fixed, and any adjustments in package.json and setup.cfg as required

this probs should be an env var for proxies - or perhaps related to #30

for services it can be a policy read from label - perhaps with (enforced) defaults

with right creds should be able to work with remote docker instance

might also allow non-privilged mode for playground container

The data received in initial dump is not always consistent with data in updates

• port mappings

probs some others

Docker errors should be turned into PlaygroundRuntimeErrors before hitting the api - which should then do something (ref #67 and #71 )

Save a world of migration pain later

So it easier to see which is which.