Ansible Jinja2 Conditional Ternary service_type with expose_service

Introduction

In Kubernetes-related automation, it’s common to toggle between NodePort and ClusterIP depending on whether a service should be exposed or not. Many Ansible users define this logic using Jinja2 inline expressions like this:

service_type: "{{ 'NodePort' if expose_service == 'true' else 'ClusterIP' }}"

However, this seemingly valid syntax often leads to confusion or unexpected behavior, especially when boolean logic and string comparisons mix. Let’s break it down and solve it correctly.

The Problem

This expression works only when the condition is a properly evaluated Python expression within Jinja2:

service_type: "{{ 'NodePort' if expose_service == 'true' else 'ClusterIP' }}"

But here’s the gotcha: if expose_service is a boolean true, this comparison to string 'true' will fail silently or incorrectly evaluate the condition.

The Fix: Use Native Booleans or Jinja2 Truthy Check

✅ Recommended:

Use Jinja2’s truthiness checks:

service_type: "{{ 'NodePort' if expose_service else 'ClusterIP' }}"

This evaluates whether expose_service is truthy (e.g., true, 'yes', 1, etc.), and assigns 'NodePort' accordingly.

📌 Make Sure expose_service Is Boolean

Ensure you’re passing a boolean value:

vars:
  expose_service: true  # not a string!

If expose_service comes from external input (like an inventory var or extra vars), normalize it:

service_type: "{{ 'NodePort' if expose_service | bool else 'ClusterIP' }}"

This guarantees the condition is treated as a proper boolean regardless of its original type.

Full Example

- name: Set service type based on exposure
  set_fact:
    service_type: "{{ 'NodePort' if expose_service | bool else 'ClusterIP' }}"

Now this works correctly whether expose_service is defined as a string ('true'), boolean (true), or passed as an extra var.

Why This Matters

Incorrect comparisons in Jinja2 can cause subtle bugs—especially when the expression seems to work but doesn’t behave consistently across environments. Using proper boolean evaluation ensures more reliable and predictable playbooks.

Conclusion

If you’ve been banging your head over a service_type not switching correctly based on expose_service, this is your solution. Ditch the string comparisons and use Jinja2’s boolean handling with | bool for clean, consistent, and robust logic.

Ansible templating is powerful—but with power comes syntax. Mastering these nuances can save hours of troubleshooting and lead to cleaner, more maintainable automation.

Academy

Learn the Ansible automation technology with real-life scenarios in my
Udemy 300+ Lessons Video Course.

My book Ansible By Examples: 200+ Automation Examples For Linux and Windows System Administrator and DevOps

Donate

Want to keep this project going? Please donate

Patreon Buy me a Pizza