Below we capture the CI/CD scenarios that we would expect with our model endpoints.
- In the
automatedbuild scenario, we capture any changes in the source code for the model server, build the new resultant docker image, push the image to the container registry, and then deploy via cloud run. This captures the CI component.
Automated builds based on changes in the
- In the
scheduledbuild scenario, to ensure that we pull the latest model from
wandbwe force the fastapi application to rebuild, which in turn queries the service for the latest recorded model. This ensures we are always serving the most up-to-date model at the endpoint.
Scheduled builds on
masterto update the endpoint with the latest model
These scenarios together complete the CI/CD flow by allowing us to define a very easy to reproduce structure for defining build triggers based on different branches.
For brevity’s sake I did not include the abstraction in this
cloudbuild.yaml however you would simply pass in a substitution variable for the
$MODEL_VERSION and pass that into the cloud console for that build for that branch. You could also abstract it by the name of the branch.
This relies on Cloud Scheduler to schedule the manual trigger run
Public API Result
python -m venv venv source venv/bin/activate make install
Running Easter Egg
Access Swagger Documentation
Access Redocs Documentation
Files related to application are in the
Application parts are:
app ├── api - web related stuff. │ └── routes - web routes. ├── core - application configuration, startup events, logging. ├── models - pydantic models for this application. ├── services - logic that is not just crud related. └── main.py - FastAPI application creation and configuration. │ tests - pytest