Deploying the Online Boutique sample application

This guide explains how to install the Online Boutique sample application to demonstrate Cloud Service Mesh. If you haven't installed Cloud Service Mesh, see the installation guide.

Downloading and deploying the sample

To deploy the application, you first need to download the Online Boutique manifests from the anthos-service-mesh-packages repo using kpt. The Online Boutique sample application in the anthos-service-mesh-packages repo is modified from the original set of manifests in the microservices-demo repo. Following best practices, each service is deployed in a separate namespace with a unique service account.

  1. Install kpt if you haven't already:

    gcloud components install kpt
    
  2. Download the sample using kpt:

    kpt pkg get \
      https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages.git/samples/online-boutique \
      online-boutique
    

    Expected output

    Package "online-boutique":
    Fetching https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages@main
    From https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages
    * branch            main       -> FETCH_HEAD
    Adding package "samples/online-boutique".
    Fetched 1 package(s).
    
  3. Navigate to the online-boutique directory:

    cd online-boutique
    
  4. Create the namespaces for the application:

    kubectl apply -f kubernetes-manifests/namespaces
    

    Expected output:

    namespace/ad created
    namespace/cart created
    namespace/checkout created
    namespace/currency created
    namespace/email created
    namespace/frontend created
    namespace/loadgenerator created
    namespace/payment created
    namespace/product-catalog created
    namespace/recommendation created
    namespace/shipping created
    
  5. Deploy the sample to the cluster.

    1. Create the service accounts and deployments:

      kubectl apply -f kubernetes-manifests/deployments
      

      Expected output:

      serviceaccount/ad created
      deployment.apps/adservice created
      serviceaccount/cart created
      deployment.apps/cartservice created
      serviceaccount/checkout created
      deployment.apps/checkoutservice created
      serviceaccount/currency created
      deployment.apps/currencyservice created
      serviceaccount/email created
      deployment.apps/emailservice created
      serviceaccount/frontend created
      deployment.apps/frontend created
      serviceaccount/loadgenerator created
      deployment.apps/loadgenerator created
      serviceaccount/payment created
      deployment.apps/paymentservice created
      serviceaccount/product-catalog created
      deployment.apps/productcatalogservice created
      serviceaccount/recommendation created
      deployment.apps/recommendationservice created
      serviceaccount/shipping created
      deployment.apps/shippingservice created
      
    2. Create the services:

      kubectl apply -f kubernetes-manifests/services
      

      Expected output:

      service/adservice created
      service/cartservice created
      service/checkoutservice created
      service/currencyservice created
      service/emailservice created
      service/frontend created
      service/frontend-external created
      service/paymentservice created
      service/productcatalogservice created
      service/recommendationservice created
      service/shippingservice created
      
    3. Create the service entries:

      kubectl apply -f istio-manifests/allow-egress-googleapis.yaml
      

      Expected output:

      serviceentry.networking.istio.io/allow-egress-googleapis created
      serviceentry.networking.istio.io/allow-egress-google-metadata created
      

Enabling sidecar auto-injection

To enable auto-injection, you label your namespaces with the default injection labels if the default tag is set up, or with the revision label to your namespace. The label that you add also depends on whether you deployed managed Cloud Service Mesh or installed the in-cluster control plane. The label is used by the sidecar injector webhook to associate injected sidecars with a particular control plane revision.

In-cluster

  1. Use the following command to locate the label on istiod:

    kubectl get deploy -n istio-system -l app=istiod -o \
      jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}'
    

    The command outputs the revision label that corresponds to the Cloud Service Mesh version, for example: asm-1187-26

  2. Apply the revision label to the application namespaces. In the following command, REVISION is the value of the istiod revision label that you noted in the previous step.

    for ns in ad cart checkout currency email frontend loadgenerator \
      payment product-catalog recommendation shipping; do
        kubectl label namespace $ns istio.io/rev=REVISION --overwrite
    done;
    

    Expected output:

    namespace/ad labeled
    namespace/cart labeled
    namespace/checkout labeled
    namespace/currency labeled
    namespace/email labeled
    namespace/frontend labeled
    namespace/loadgenerator labeled
    namespace/payment labeled
    namespace/product-catalog labeled
    namespace/recommendation labeled
    namespace/shipping labeled
    
  3. Restart the pods:

    for ns in ad cart checkout currency email frontend loadgenerator \
      payment product-catalog recommendation shipping; do
        kubectl rollout restart deployment -n ${ns}
    done;
    

    Expected output:

    deployment.apps/adservice restarted
    deployment.apps/cartservice restarted
    deployment.apps/checkoutservice restarted
    deployment.apps/currencyservice restarted
    deployment.apps/emailservice restarted
    deployment.apps/frontend restarted
    deployment.apps/loadgenerator restarted
    deployment.apps/paymentservice restarted
    deployment.apps/productcatalogservice restarted
    deployment.apps/recommendationservice restarted
    deployment.apps/shippingservice restarted
    

Managed service mesh

  1. Apply the revision label to the application namespaces. In the following command, the REVISION label must be the value of your managed Cloud Service Mesh release channel: asm-managed for regular, asm-managed-rapid for rapid, or asm-managed-stable for stable.

    for ns in ad cart checkout currency email frontend loadgenerator \
      payment product-catalog recommendation shipping; do
        kubectl label namespace $ns istio.io/rev=REVISION --overwrite
    done;
    

    Expected output:

    namespace/ad labeled
    namespace/cart labeled
    namespace/checkout labeled
    namespace/currency labeled
    namespace/email labeled
    namespace/frontend labeled
    namespace/loadgenerator labeled
    namespace/payment labeled
    namespace/product-catalog labeled
    namespace/recommendation labeled
    namespace/shipping labeled
    
  2. If you also deployed the optional managed data plane, annotate the application namespaces as follows:

    for ns in ad cart checkout currency email frontend loadgenerator \
      payment product-catalog recommendation shipping; do
        kubectl annotate --overwrite namespace $ns mesh.cloud.google.com/proxy='{"managed":"true"}'
    done;
    
  3. Restart the pods:

    for ns in ad cart checkout currency email frontend loadgenerator \
      payment product-catalog recommendation shipping; do
        kubectl rollout restart deployment -n ${ns}
    done;
    

    Expected output:

    deployment.apps/adservice restarted
    deployment.apps/cartservice restarted
    deployment.apps/checkoutservice restarted
    deployment.apps/currencyservice restarted
    deployment.apps/emailservice restarted
    deployment.apps/frontend restarted
    deployment.apps/loadgenerator restarted
    deployment.apps/paymentservice restarted
    deployment.apps/productcatalogservice restarted
    deployment.apps/recommendationservice restarted
    deployment.apps/shippingservice restarted
    

Exposing and accessing the application

The way you expose the application outside the mesh depends on whether you deployed an ingress gateway. You can choose to expose the application using an istio ingress gateway or using a Kubernetes Service.

Using ingress gateway

If you deployed an ingress gateway to the cluster as specified in the prerequisite, do the following steps to expose the application using the gateway.

  1. Deploy a Gateway and VirtualService for the frontend service

    kubectl apply -f istio-manifests/frontend-gateway.yaml
    

    Expected output:

    gateway.networking.istio.io/frontend-gateway created
    virtualservice.networking.istio.io/frontend-ingress created
    
  2. Get the external IP address of the ingress gateway. Replace the placeholders with the following information:

    • GATEWAY_SERVICE_NAME : The name of the ingress gateway service. If you deployed the sample gateway without modification, or if you deployed the default ingress gateway, the name is istio-ingressgateway.

    • GATEWAY_NAMESPACE: The namespace in which you deployed the ingress gateway. If you deployed the default ingress gateway, the namespace is istio-system.

    kubectl get service GATEWAY_SERVICE_NAME  -n GATEWAY_NAMESPACE
    

    The output is similar to:

    NAME                   TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)                                      AGE
    istio-ingressgateway   LoadBalancer   10.19.247.233   35.239.7.64   80:31380/TCP,443:31390/TCP,31400:31400/TCP   27m
    

    In this example, the IP address of the ingress gateway is 35.239.7.64.

  3. Visit the application on your browser to confirm installation:

    http://EXTERNAL_IP/
    

No ingress gateway

If you did not deploy an ingress gateway or choose to expose the application using a Kubernetes Service, do the following steps:

  1. Deploy a service of type LoadBalancer to expose the frontend service

    kubectl apply -f frontend-external.yaml
    
  2. Find the external IP address of the frontend-external service:

    kubectl get service frontend-external -n frontend
    
  3. Visit the application on your browser to confirm installation:

    http://EXTERNAL_IP/
    

You can explore the Cloud Service Mesh observability features in the Google Cloud console. Note that it can take up to 10 minutes for the topology graph to display the services in your mesh.

Clean up

Before deleting Online Boutique, you might want to work through Cloud Service Mesh by example: mTLS, which uses the sample. When you're finished exploring, use the following commands to remove the Online Boutique sample:

  1. Delete the application namespaces:

    kubectl delete -f kubernetes-manifests/namespaces
    

    Expected output:

    namespace "ad" deleted
    namespace "cart" deleted
    namespace "checkout" deleted
    namespace "currency" deleted
    namespace "email" deleted
    namespace "frontend" deleted
    namespace "loadgenerator" deleted
    namespace "payment" deleted
    namespace "product-catalog" deleted
    namespace "recommendation" deleted
    namespace "shipping" deleted
    
  2. Delete the service entries:

    kubectl delete -f istio-manifests/allow-egress-googleapis.yaml
    

    Expected output:

    serviceentry.networking.istio.io "allow-egress-googleapis" deleted
    serviceentry.networking.istio.io "allow-egress-google-metadata" deleted
    

What's next?