Skip to content
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

Pulling changes from master #43

Merged
merged 5 commits into from Oct 8, 2019
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
4 changes: 2 additions & 2 deletions Dockerfile
Expand Up @@ -8,7 +8,7 @@ WORKDIR /src/app
COPY . .

# Install app dependencies and build static files
RUN mkdir _site && \
RUN mkdir _site && mkdir .jekyll-cache && \
jekyll build --future

#
Expand All @@ -20,4 +20,4 @@ FROM nginx:1.15-alpine
WORKDIR /usr/share/nginx/html
COPY --from=build /src/app/_site .

EXPOSE 80
EXPOSE 80
2 changes: 1 addition & 1 deletion _entries/03-07 networking.md
Expand Up @@ -11,7 +11,7 @@ Let's review how this application is set up...

![OSToy Diagram](/media/managedlab/4-ostoy-arch.png)

As can be seen in the image above we see we have defined at least 2 separate pods, each with its own service. One is the frontend web application (with a service and a publicly accessible route) and the other is the backend microservice with a service object created so that the frontend pod can communicate with the microservice (accross the pods if more than one). Therefore this microservice is not accessible from outside this cluster, nor from other namespaces/projects (due to ARO's network policy, **ovs-subnet**). The sole purpose of this microservice is to serve internal web requests and return a JSON object containing the current hostname and a randomly generated color string. This color string is used to display a box with that color displayed in the tile (titled "Intra-cluster Communication").
As can be seen in the image above we see we have defined at least 2 separate pods, each with its own service. One is the frontend web application (with a service and a publicly accessible route) and the other is the backend microservice with a service object created so that the frontend pod can communicate with the microservice (accross the pods if more than one). Therefore this microservice is not accessible from outside this cluster, nor from other namespaces/projects (due to ARO's network policy, **ovs-networkpolicy**). The sole purpose of this microservice is to serve internal web requests and return a JSON object containing the current hostname and a randomly generated color string. This color string is used to display a box with that color displayed in the tile (titled "Intra-cluster Communication").

### Networking

Expand Down