-
Notifications
You must be signed in to change notification settings - Fork 885
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
docs(docker) Add ServerApps docs #3439
Conversation
3895c65
to
9c2fea8
Compare
Signed-off-by: Robert Steiner <robert@flower.ai>
9c2fea8
to
7a48176
Compare
If the requirement.txt contains the `flwr <https://pypi.org/project/flwr/>`__ or | ||
`flwr-nightly <https://pypi.org/project/flwr-nightly/>`_ package, please ensure the version in | ||
requirement.txt matches the docker image version. |
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.
AFAIK, we can skip installing flwr
as long as the correct Docker image is used. Maybe we can rephrase as:
⚠️ Note thatflwr
is already installed in theflwr/supernode
base image, so you only need to include other package dependencies in yourrequirements.txt
, such astorch
,tensorflow
, etc ...
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.
I think the way you phrased it sounds better. I will go with that. The reason I included the note is because I'm afraid users develop locally with a requirements.txt containing the flwr package and once they're done they just copy the same file into the Docker image.
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.
I can see why that can be the case. Since this is a self-contained "How-to" page, I think it's important to start from the simplest setup. This basic Dockerfile can then be expanded by users for other more complicated server setups.
A key difference is the additional argument in the ``ENTRYPOINT`` command of the ServerApp | ||
Dockerfile. |
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.
"A key difference is the different argument in the ENTRYPOINT
command of the ServerApp Dockerfile."
The server:app
argument can be passed in the same way as the client:app
argument.
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.
I removed it.
. | ||
├── server.py # ServerApp code | ||
├── task.py # ServerApp code | ||
├── requirements.txt # ServerApp dependencies |
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.
Technically, ServerApp
does not need any other packages other than flwr
. Let's remove requirements.txt
as one of the required files in this tree.
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.
In the examples/app-pytorch
I need therequirements.txt
because the ServerApp code uses the pytorch package but we can create our own example. wdyt?
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.
Yes, let's adapt the examples. In fact, the quickstart-pytorch
example is a better example to base this "How-to" on. For context, the app-pytorch
uses a server-side model parameter intialization - that's why PyTorch is a dependency for running the ServerApp
. For the quickstart-pytorch
, it is a client-side parameter initialization - so all ML-related computation is done in the ClientApp
. Can you please update the references to quickstart-pytorch
instead?
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.
Oh I didn't know that. That makes sense! I will update it to use the quickstart-pytorch example instead.
COPY requirements.txt . | ||
RUN python -m pip install -U --no-cache-dir -r requirements.txt && pyenv rehash |
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.
We can remove requirements.txt
and the installation of it in the ServerApp's Dockerfile.
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.
Done 👍
.. important:: | ||
|
||
If the requirement.txt contains the `flwr <https://pypi.org/project/flwr/>`__ or | ||
`flwr-nightly <https://pypi.org/project/flwr-nightly/>`_ package, please ensure the version in | ||
requirement.txt matches the docker image version. | ||
|
||
Stable: | ||
|
||
- Docker image: ``serverapp:1.8.0`` | ||
- requirement.txt: ``flwr[simulation]==1.8.0`` | ||
|
||
Nightly: | ||
|
||
- Docker image: ``serverapp:1.9.0.dev20240501`` | ||
- requirement.txt: ``flwr-nightly[simulation]==1.9.0.dev20240501`` |
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.
Since flwr
is already installed in the base image, we can skip this step. Let's remove these lines.
|
||
$ docker run --rm flwr_serverapp:0.0.1 \ | ||
--insecure \ | ||
--server 192.168.1.100:9091 |
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.
Should we adopt the Docker network approach here (and also for SuperLink
and SuperNode
)? I think it will be clearer overall since we can just use the --name
instead of an IP address --server
.
docker run \
--network flwr-net \
--rm flwr/serverapp:1.8.0 \
--insecure --server flwr-superlink:9091
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.
I'm not sure since this only works if all containers are running on the same machine. We could add a note wdyt?
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.
That's true. Maybe something like the following?
💡 To test running Flower locally, use the
--network
argument and pass the name of the Docker network to run yourServerApp
s.
Or did you have another comment in mind?
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.
I took your comment and added a link to the Docker documentation on creating a bridge network.
|
||
.. code-block:: bash | ||
|
||
$ docker run --rm -v ./ca.crt:/app/ca.crt flwr_serverapp:0.0.1 client:app \ |
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.
Let's use the full argument for consistency: docker run --rm --volume ...
Signed-off-by: Robert Steiner <robert@flower.ai>
Signed-off-by: Robert Steiner <robert@flower.ai>
@@ -117,7 +123,7 @@ building your own SuperNode image. | |||
day. To ensure the versions are in sync, using the concrete tag, e.g., ``1.9.0.dev20240501`` | |||
instead of ``nightly`` is recommended. | |||
|
|||
We will use the ``app-pytorch`` example, which you can find in | |||
We will use the ``quickstart-pytorch`` example, which you can find in | |||
the Flower repository, to illustrate how you can dockerize your client-app. |
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.
Rename client-app > ClientApp for consistency.
@@ -126,14 +132,14 @@ Prerequisites | |||
~~~~~~~~~~~~~ | |||
|
|||
Before we can start, we need to meet a few prerequisites in our local development environment. | |||
You can skip the first part if you want to run your client-app instead of the ``app-pytorch`` | |||
You can skip the first part if you want to run your client-app instead of the ``quickstart-pytorch`` |
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.
Rename client-app > ClientApp for consistency.
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.
Good catch!
Signed-off-by: Robert Steiner <robert@flower.ai>
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.
LGTM! I only have minor formatting comments.
example. | ||
|
||
#. Clone the flower repository. | ||
|
||
.. code-block:: bash | ||
|
||
$ git clone https://github.com/adap/flower.git && cd flower/examples/app-pytorch | ||
$ git clone https://github.com/adap/flower.git && cd flower/examples/quickstart-pytorch |
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.
- git clone https://github.com/adap/flower.git && cd flower/examples/quickstart-pytorch
+ git clone --depth=1 https://github.com/adap/flower.git && cd flower/examples/quickstart-pytorch
@@ -126,14 +132,14 @@ Prerequisites | |||
~~~~~~~~~~~~~ | |||
|
|||
Before we can start, we need to meet a few prerequisites in our local development environment. | |||
You can skip the first part if you want to run your client-app instead of the ``app-pytorch`` | |||
You can skip the first part if you want to run your client-app instead of the ``quickstart-pytorch`` | |||
example. | |||
|
|||
#. Clone the flower repository. |
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.
flower > Flower
base image, so you only need to include other package dependencies in your requirements.txt, | ||
such as torch, tensorflow, etc. |
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.
... in your requirements.txt
such as torch
, tensorflow
, etc.
|
||
- Docker image: ``supernode:1.9.0.dev20240501`` | ||
- requirement.txt: ``flwr-nightly[simulation]==1.9.0.dev20240501`` | ||
we copy the ClientApp code into the image and set the entry point to ``flower-client-app`` with |
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.
we copy the client.py
module into the image ...
|
||
- Docker image: ``serverapp:1.9.0.dev20240501`` | ||
- requirement.txt: ``flwr-nightly[simulation]==1.9.0.dev20240501`` | ||
executed in the ``/app`` directory. In the last two lines, we copy the ServerApp code into the |
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.
..., we copy the ServerApp
module into the ...
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.
Should we call it ServerApp
or server.py
to be consistent with change above?
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.
You're right @Robert-Steiner! Let's stick to server.py
.
..., we copy the
server.py
module into the ...
Signed-off-by: Robert Steiner <robert@flower.ai>
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.
LGTM, thanks @Robert-Steiner!
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.
lgtm!
Issue
Description
Related issues/PRs
Proposal
Explanation
Checklist
#contributions
)Changelog entry
Any other comments?