Updating a Virtual Service

• Console
• CLI
• API

• 1. Open the navigation menu and click Developer Services. Under Containers & Artifacts, click Service Mesh.
  2. Click Service Meshes.
  3. On the Service Mesh page, from the list of compartments on the left side, select a compartment.
  4. From the list of meshes, click the mesh name that contains the virtual services.
  5. On the details page, click the name of the virtual service that you want to update.
  6. On the details page of the virtual service, click Edit.
  7. On the Edit Virtual Service panel, update the details as required. You can modify the description, default routing policy, mTLS mode, and the maximum validity of the certificates.
  8. Click Save changes.

• To see what operations are available for virtual-service update use:

  oci service-mesh virtual-service update -h

  To update a virtual service using the CLI, use the oci service-mesh virtual-service update option:

  oci service-mesh virtual-service update --virtual-service-id <virtualServiceId> --description <description> --default --routing-policy <defaultRoutingPolicy> --hosts <hosts> --mtls <mtls>

  Where:

  • <virtualServiceId>: The OCID of the virtual service to update. To find out the Virtual Service's OCID, see Listing Virtual Services.
  • <description>: (Optional) The description of the virtual service. Avoid entering confidential information.
  • <defaultRoutingPolicy>: The default routing policy across virtual deployments within a virtual service. If no virtual service route tables are present, the virtual service applies the default routing policy. Options are DENY or UNIFORM. The default routing policy is DENY. Specify the parameter with a key of type and value of the selected routing option. The parameter must be in valid JSON format (either as a string, or passed in as a file using the file:///<filename> syntax including a path).

    The routing options are as follows:

    • Uniform: Distributes traffic uniformly across virtual deployments.
    • Deny: The default option. Disables routing. Sends no traffic to the virtual deployments.

    For more information, see Routing Traffic in a Virtual Service.

  • <hosts>The DNS host names of the virtual service used by its callers. Supports wild card host names in prefix form. Specify up to 10 DNS host names. The following are examples of valid host names: www.example.com, *.example.com, *.com, www.example.com:9080, *.example.com:9080. Can be omitted if the virtual service only has TCP virtual deployments. The value for <hosts> must be in valid JSON format (either as a string, or passed in as a file using the file:///<filename> syntax including a path).
    Warning
    
    Don’t use the following service mesh reserved ports in this resource: 15000, 15003, 15006, and 9901.

    For services with HTTP based virtual deployments, the host name must match the HTTP host header used to communicate with the service. If a mismatch occurs, the applications connecting to this service receives 404 errors. The HTTP host header is of the form example.com for standard ports 80 and 443. For a nonstandard port such as 9080, the host header is of the form example.com:9080.

    For services with virtual deployments based on TLS_PASSTHROUGH, the host name must match the server name indication (SNI) used to communicate with the service. If a mismatch occurs, the applications connecting to this service receives TLS handshake errors. The service allows wild cards in the prefix form but doesn't allow a blanket wild card: *.

    SNI is similar to HTTP host headers but for TLS. However, port information isn’t required for SNI. For example, if you’re running a Kubernetes service on SNI example.com and on a nonstandard port 9080, you must define example.com as a host on the virtual service.

    Important
    
    Hosts entries aren’t required for egress-only services. Egress-only services are microservices that don’t receive any calls from other services.
  • <mtls>The mTLS authentication mode to use when receiving requests from other virtual services or ingress gateways within the mesh. Set mTLS <mode> to DISABLED, PERMISSIVE, or STRICT as described in the following list. Additionally, specify <maximumValidity> to determine the number of days the mTLS certificate is valid for. Specify a value between 45 and 90. The default value is 45 days. The value of <mtls> must be in valid JSON format (either as a string, or passed in as a file using the file:///<filename> syntax including a path).
    • Disabled: Accept raw TCP traffic. No minimum virtual services within this mesh can use any mTLS authentication mode.
    • Permissive: Accept both mTLS and raw TCP traffic. Virtual services within this mesh are either PERMISSIVE or STRICT modes.
    • Strict: Accept mTLS traffic. All virtual services within this mesh must use STRICT mode.

    For more information on using mTLS on Service Mesh, see Using mTLS with Service Mesh.

  For example:

  oci service-mesh virtual-service update --virtual-service-id ocid1.meshvirtualservice.oc1..aaa... --description "my virtual-service updated" --default-routing-policy '{"type":"UNIFORM"}' --hosts '["www.example.com"]' --mtls '{"maximum-validity":45,"mode":"STRICT"}'

  The response to the command includes:

  • The virtual service OCID.
  • The life cycle state (for example, ACTIVE, FAILED).
  • The ID of the work request to update the virtual service. Details of work requests are available for seven days after completion, cancellation, or failure.

  If you want the command to wait to return control until the virtual service is active or the request has failed, include either or both of the following parameters:

  • --wait-for-state SUCCEEDED
  • --wait-for-state FAILED

  For example:

  oci service-mesh virtual-service update --virtual-service-id ocid1.meshvirtualservice.oc1..aaa... --description "my virtual-service updated" --default-routing-policy '{"type":"UNIFORM"}' --hosts '["www.example.com"]' --mtls '{"maximum-validity":45,"mode":"STRICT"}' --wait-for-state SUCCEEDED

  Note
  
  You can't use the Virtual Service until the work request has successfully updated it and the Virtual Service is active.

  Checking Virtual Service Status

  To see the status of the virtual service, enter:

  oci service-mesh virtual-service get --virtual-service-id <virtualServiceId>

  To view the status of the work request creating the virtual service, refer to Service Mesh Work Requests.

  Updating a Virtual Service using a JSON File

  Alternatively, update a virtual service by supplying a JSON file to the update command.

  1. Generate a sample JSONs file for a virtual service:

     oci service-mesh virtual-service update --generate-full-command-json-input

  2. Create a JSON file with the sample generated output.
  3. Update the fields with appropriate values.
  4. Supply the JSON file to the virtual-service update command:

     oci service-mesh virtual-service update --from-json file:///<filename>

  For more information about using the CLI, see:

  • Command Line Interface (CLI)
  • Service Mesh CLI Reference

• Use the UpdateVirtualService operation to update a virtual service.