If you just want the quickest option then go for a playbook.
If you can spend some time on this then you could create a role that is meant for patching ESX hosts, and that includes helper tasks to handle the maintenance mode and the reboot.
Endless possibilities to do this, from quick and dirty to nicely parametrised
Hmmm. My reply did not post. Maybe I replied to the user?
Anyway, my vote is to consider “roles” to be an enhancement. I have to be very certain I’m going to reuse the role before I will create it. If I’m not sure, then I call the creation of a role “gold plating” and unnecessary. So, I will create a straight playbook if there’s any doubt in my mind about whether this is a reusable task. That does mean when the time comes to reuse the tasks that would be in the role, I need to refactor the original play to role-ify it, but that’s pretty light work. I’d rather be certain I don’t gold plate any plays than end up with a bunch of single-use roles cluttering my project.
If this is the only thing you’re planning on doing with Ansible, I would go for a single playbook. In my repository, I have roles for enter_maintenance_mode and exit_maintenance_mode, since that function is used in multiple contexts.
In my environment rather than performing a SSH to ESXi and run esxcli command, which either you need to enable shell each time, or have that turned on permanently, which leaves a security risk,. I’d rather use PowerCLI. PS7 on Linux or Mac works fine with PowerCLI. I keep that to apply Host Profiles and other functions where there are no native vmware modules.
I have a PowerShell / PowerCLI delegate host dedicated for tasks which do not have native modules, and delegate those tasks to the delegate host.