We use skaffold and minikube for local development. Every engineer uses these to launch a local development k8s cluster for developing in. We have routes corresponding to the following microservices:
For example, the minikube ip would be 192.168.64.3 and the routes above appended to it.
The routes / and /api work just fine.
The /admin is the problematic one and after hours of trying to get it to serve the static assets properly, "homepage:" was not designed to work with npm start.
Even though you get the following console output when starting up the cluster:
[admin]
[admin] > adminv2@0.1.0 start /app
[admin] > PORT=4050 react-scripts start
[admin]
[admin] ℹ 「wds」: Project is running at http://172.17.0.8/
[admin] ℹ 「wds」: webpack output is served from /admin
[admin] ℹ 「wds」: Content not from webpack is served from /app/public
[admin] ℹ 「wds」: 404s will fallback to /admin/
[admin] Starting the development server...
[admin]
[admin] Compiled successfully!
[admin]
[admin] You can now view admin in the browser.
[admin]
[admin] Local: http://localhost:4050/admin
[admin] On Your Network: http://172.17.0.8:4050/admin
[admin]
[admin] Note that the development build is not optimized.
[admin] To create a production build, use npm run build.
[admin]
Navigating to 192.168.64.3/admin is just a blank page with the following dev console ouputs:
Describe the solution you'd like
I'd like to be able to navigate 192.168.64.3/admin and have it serve that microservice correctly with npm start... for "homepage:" to also apply to dev deployments and not just npm build.
Describe alternatives you've considered
Only this is what I've found that is recommended:
# package.json
...
"homepage": "/client"
...
# App.js
<BrowserRouter basename={process.env.PUBLIC_URL}>
{/* other components */}
</BrowserRouter>
Two other things do work, but they aren't desirable:
localhost:4050/admin: works, but isn't desirable as it will circumvent some k8s routing issues that will come up in staging and production (an issue I encountered with the Django Admin portal which has made me reluctant to use localhost ever since). And just testing it now with /, it is unable to communicate with /api when using localhost:3000 (the port for /). So basically doesn't work.
Using a production / staging build configuration of Dockerfile that uses npm build... not desirable because I lose the debugging outputs.
I considered just combining the / and /admin microservices into one service and /admin just being a <Route path="/admin">, but no... these are entirely separate services who need their own CI / CD pipelines.
Additional context
Here is code for reference and the create-react-app is basically a clean install of npx create-react-app admin:
# index.js
import React from "react";
import ReactDOM from "react-dom";
import { BrowserRouter as Router, Route, Switch } from "react-router-dom";
import App from "./App";
import * as serviceWorker from "./serviceWorker";
ReactDOM.render(
<Router basename={process.env.PUBLIC_URL}>
<Switch>
<Route path="/">
<App />
</Route>
</Switch>
</Router>,
document.getElementById("root")
);
// If you want your app to work offline and load faster, you can change
// unregister() to register() below. Note this comes with some pitfalls.
serviceWorker.unregister();
And as expected, this does work properly when using a Dockerfile production build, which isn't exactly helpful in dev:
# Dockerfile
FROM node:13-alpine as builder
WORKDIR /app
COPY ./package.json ./
RUN npm install
COPY . .
RUN npm run build
FROM nginx
EXPOSE 4050
COPY ./nginx/default.conf /etc/nginx/conf.d/default.conf
COPY --from=builder /app/build /usr/share/nginx/html
Is your proposal related to a problem?
Yes.
We use
skaffold
andminikube
for local development. Every engineer uses these to launch a local development k8s cluster for developing in. We have routes corresponding to the following microservices:/
: client facingcreate-react-app
application/admin
: internally facingcreate-react-app
application/api
: Django backendFor example, the
minikube ip
would be192.168.64.3
and the routes above appended to it.The routes
/
and/api
work just fine.The
/admin
is the problematic one and after hours of trying to get it to serve the static assets properly,"homepage:"
was not designed to work withnpm start
.Even though you get the following console output when starting up the cluster:
Navigating to
192.168.64.3/admin
is just a blank page with the following dev console ouputs:Describe the solution you'd like
I'd like to be able to navigate
192.168.64.3/admin
and have it serve that microservice correctly withnpm start
... for"homepage:"
to also apply to dev deployments and not justnpm build
.Describe alternatives you've considered
Only this is what I've found that is recommended:
Two other things do work, but they aren't desirable:
localhost:4050/admin
: works, but isn't desirable as it will circumvent some k8s routing issues that will come up in staging and production (an issue I encountered with the Django Admin portal which has made me reluctant to uselocalhost
ever since). And just testing it now with/
, it is unable to communicate with/api
when usinglocalhost:3000
(the port for/
). So basically doesn't work.Dockerfile
that usesnpm build
... not desirable because I lose the debugging outputs./
and/admin
microservices into one service and/admin
just being a<Route path="/admin">
, but no... these are entirely separate services who need their own CI / CD pipelines.Additional context
Here is code for reference and the
create-react-app
is basically a clean install ofnpx create-react-app admin
:And as expected, this does work properly when using a
Dockerfile
production build, which isn't exactly helpful in dev: