Create your own Telegram bot with Django on Heroku – Part 8 – Integrating the database

Header Image showing Django, Telegram, Heroku logos
This entry is part 8 of 8 in the series Create your own Telegram bot with Django on Heroku

Django_Pony

In the previous part of this series, we had a bit of a term definition to make it easier for beginners of Django to understand what I am talking about. Also, we created a Django – App called “bot” and created a URL routing for it to be available at (https://dry-tundra-61874.herokuapp.com)/bot/* (or whatever your URL looks like) and how to direct URLs to a view.

Originally, I planned to also show how to start using a database in Django to hold your bot’s data. But since the article grew larger than I anticipated before, I had to cut that down, unfortunately (sorry for that 😰).
Today, I will deliver that part in its own article. We will learn how to work with databases in Django, what migrations are and how to interact with the database from within Django’s Admin-Backend.
Continue reading “Create your own Telegram bot with Django on Heroku – Part 8 – Integrating the database”

Born in 1982, Marc Richter is an IT enthusiastic since 1994. He became addicted when he first put hands on their family’s pc and never stopped investigating and exploring new things since then.
He is married to Jennifer Richter and proud father of two wonderful children, Lotta and Linus.
His current professional focus is DevOps and Python development.

An exhaustive bio can be found at this blog post.

Found my articles useful? Maybe you would like to support my efforts and give me a tip then?

Create your own Telegram bot with Django on Heroku – Part 7 – Introducing apps and URLconf

Header Image showing Django, Telegram, Heroku logos
This entry is part 7 of 8 in the series Create your own Telegram bot with Django on Heroku

 

Django_Pony

In the previous part of this series, we started with the basics for kicking off a new Django project. We prepared our virtualenv, installed needed modules to it, created and integrated a new Heroku – project for it and learned how to work with variables in Heroku to control our application with an easy example. We also learned how to check our results locally before we publish it to our production space and how we can add an addon to our Heroku project by adding a PostgreSQL database to it.

Today, we will learn what an “app” is in Django and how to create it. Also, we will learn about and create a so-called URLconf / routing to direct specific URLs to specific parts of our code.
Continue reading “Create your own Telegram bot with Django on Heroku – Part 7 – Introducing apps and URLconf”

Born in 1982, Marc Richter is an IT enthusiastic since 1994. He became addicted when he first put hands on their family’s pc and never stopped investigating and exploring new things since then.
He is married to Jennifer Richter and proud father of two wonderful children, Lotta and Linus.
His current professional focus is DevOps and Python development.

An exhaustive bio can be found at this blog post.

Found my articles useful? Maybe you would like to support my efforts and give me a tip then?

Create your own Telegram bot with Django on Heroku – Part 6 – Creating the Django app

Header Image showing Django, Telegram, Heroku logos
This entry is part 6 of 8 in the series Create your own Telegram bot with Django on Heroku

 

 

Django_Pony

In the previous part of this series, I tried to give you a brief yet thorough introduction to hosting your projects with Heroku.
That part was special because it was a completely optional part of this series; if you prefer to host your applications on a different platform and skipped that article, I’d like to repeat that this is completely OK and that I had shown nothing you will need for anything different but interacting with Heroku. You will hopefully notice no blank spots in the following articles. There is no need to read that article if you do not plan to use Heroku for hosting your bot. But you should be familiar enough with your hosting solution of choice to adopt the Heroku – commands I show here to an adequate setup for your hosting solution.

Today we will finally start creating our bot with Django. What we did up until now was just some kind of preparation and establishing background. In this part, we will finally start with the real stuff. 💪

Continue reading “Create your own Telegram bot with Django on Heroku – Part 6 – Creating the Django app”

Born in 1982, Marc Richter is an IT enthusiastic since 1994. He became addicted when he first put hands on their family’s pc and never stopped investigating and exploring new things since then.
He is married to Jennifer Richter and proud father of two wonderful children, Lotta and Linus.
His current professional focus is DevOps and Python development.

An exhaustive bio can be found at this blog post.

Found my articles useful? Maybe you would like to support my efforts and give me a tip then?

Create your own Telegram bot with Django on Heroku – Part 5 – Introduce Heroku

Header Image showing Django, Telegram, Heroku logos
This entry is part 5 of 8 in the series Create your own Telegram bot with Django on Heroku

In the previous part of this series, I tried to explain the differences in the two modes a Telegram bot supports: pull (getUpdates) and push (Webhook) methods. I also explained what a webhook is and how to easily giving it a test-drive, without any hassle.

Today we will talk about what Heroku is and about how to prepare your workstation to effectively work with that platform.

If you do not like Heroku or if you simply want to use another hosting service for your bot like AWS, OpenShift, Google Cloud Platform, whatever for any reason: That is perfectly OK and you can do so! I will write this and the next article on Heroku in a way that even when you decide to skip it completely, you won’t miss anything from this Telegram/Python/Django article series but the presentation of how to get the bot hosted on Heroku.
The only thing which you won’t be able to follow 1:1 in the upcoming parts of this series is that you can’t use those commands to trigger new deployments to the hosting platform with or do some minor, hosting platform related steps. But if you are advanced and familiar enough with deploying web applications to have a better idea of hosting an application than me, this shouldn’t be much of a problem for you, since most commands for Heroku are pretty straightforward and easy to adapt for a different system.

Continue reading “Create your own Telegram bot with Django on Heroku – Part 5 – Introduce Heroku”

Born in 1982, Marc Richter is an IT enthusiastic since 1994. He became addicted when he first put hands on their family’s pc and never stopped investigating and exploring new things since then.
He is married to Jennifer Richter and proud father of two wonderful children, Lotta and Linus.
His current professional focus is DevOps and Python development.

An exhaustive bio can be found at this blog post.

Found my articles useful? Maybe you would like to support my efforts and give me a tip then?

Create your own Telegram bot with Django on Heroku – Part 4 – pull vs. push method

Header Image showing Django, Telegram, Heroku logos
This entry is part 4 of 8 in the series Create your own Telegram bot with Django on Heroku

In the previous part of this series, we started to get familiar with telepot, a Python module to interact with Telegram bots and had a short look at how the Telegram bot API is providing messages as JSON structures.

Today we will talk about the Webhook-method (push) instead of the previously introduced getUpdate-method (pull).

Continue reading “Create your own Telegram bot with Django on Heroku – Part 4 – pull vs. push method”

Born in 1982, Marc Richter is an IT enthusiastic since 1994. He became addicted when he first put hands on their family’s pc and never stopped investigating and exploring new things since then.
He is married to Jennifer Richter and proud father of two wonderful children, Lotta and Linus.
His current professional focus is DevOps and Python development.

An exhaustive bio can be found at this blog post.

Found my articles useful? Maybe you would like to support my efforts and give me a tip then?

Create your own Telegram bot with Django on Heroku – Part 3

Header Image showing Django, Telegram, Heroku logos
This entry is part 3 of 8 in the series Create your own Telegram bot with Django on Heroku

In the previous part of this series, I explained how to register bots on Telegram, how to configure it and how to validate everything is working.

Today I will explain a bit more on how the HTTP API works, how the JSON data provided by the bots ist structured and I will introduce you to telepot, the Python module of my choice for interacting with Telegram bots using Python.

Continue reading “Create your own Telegram bot with Django on Heroku – Part 3”

Born in 1982, Marc Richter is an IT enthusiastic since 1994. He became addicted when he first put hands on their family’s pc and never stopped investigating and exploring new things since then.
He is married to Jennifer Richter and proud father of two wonderful children, Lotta and Linus.
His current professional focus is DevOps and Python development.

An exhaustive bio can be found at this blog post.

Found my articles useful? Maybe you would like to support my efforts and give me a tip then?

Create your own Telegram bot with Django on Heroku – Part 2

Header Image showing Django, Telegram, Heroku logos
This entry is part 2 of 8 in the series Create your own Telegram bot with Django on Heroku

In the previous part of this series, I introduced the overall idea about what we are trying to achieve and what’s the goal of it.

Today I will show you how to register and prepare your Bot using the Telegram app.

Continue reading “Create your own Telegram bot with Django on Heroku – Part 2”

Born in 1982, Marc Richter is an IT enthusiastic since 1994. He became addicted when he first put hands on their family’s pc and never stopped investigating and exploring new things since then.
He is married to Jennifer Richter and proud father of two wonderful children, Lotta and Linus.
His current professional focus is DevOps and Python development.

An exhaustive bio can be found at this blog post.

Found my articles useful? Maybe you would like to support my efforts and give me a tip then?

Create your own Telegram bot with Django on Heroku – Part 1

Header Image showing Django, Telegram, Heroku logos
This entry is part 1 of 8 in the series Create your own Telegram bot with Django on Heroku

Recently, I finished my first Django application ✌. Since it took me some time to find a proper starting point to wrap my head around the basics of Django well enough to actually do something with it (apart from following tutorials, which pretty much all aim for creating a polling app for any reason 😋), I’d like to recap and share that journey by writing this article about that.

I will describe the project, my thoughts and considerations about it and every step which has lead to what the project has become. I will try my best to make this a guide which everybody can follow along if he wants.

Also, I will make this a series, to not end up with an article so long and boring, that even interested readers cannot afford to read it in their spare time.
In this first part of the series, I will explain what this series will be about, mainly.

Continue reading “Create your own Telegram bot with Django on Heroku – Part 1”

Born in 1982, Marc Richter is an IT enthusiastic since 1994. He became addicted when he first put hands on their family’s pc and never stopped investigating and exploring new things since then.
He is married to Jennifer Richter and proud father of two wonderful children, Lotta and Linus.
His current professional focus is DevOps and Python development.

An exhaustive bio can be found at this blog post.

Found my articles useful? Maybe you would like to support my efforts and give me a tip then?

More recent Python in Enterprise Linux like CentOS and RHEL

Tux

This article describes what “Enterprise Linux” is and how to add a more recent version of Python to it than those available in the base package repository.

What is “Enterprise Linux”?

General definition

CentOS and RedHat Enterprise Linux (RHEL) both are counted as one of the so-called “Enterprise Linux” systems. This term is an artificial noun, which has different meanings. In general, this describes Linux distributions, which are targeted at the commercial market thus putting a strong focus on reliability and long lifecycles.
CentOS, RHEL and SUSE Linux Enterprise Server (SLES) usually maintains a release for 10 years; RHEL and SLES even offer extended support contracts for additional years of support. That means these distributions offer at least twice as long support for a version than Ubuntu LTS versions does (which usually is ~5 years).

This kind of distribution’s biggest strength often is also one of their biggest downsides: If you want to have a more recent version of any of the software they contain, you often have bad luck. More recent versions (if any are available at all) usually come from 3rd party repositories. One of the most famous ones for CentOS is EPEL (Extra Packages for Enterprise Linux), which ports a lot of “had expected that to be available” – like packages from Fedora to Enterprise Linux.
But the more repositories you add, the more unpredictable and unreliable the core becomes.

RedHat based definition

But there’s also another meaning: The term “Enterprise Linux” also has established as a term to group distributions, which are based on blueprints from RedHat Enterprise Linux or build alike it. Some sources refer to this kind of distributions like this (like EPEL, for example). This list normally includes (but is not limited to):

RedHat Family Tree
RedHat Family Tree

This does not mean in any way, that other distributions, not based on RHEL, are not enterprise class or ready!

What are Enterprise Linux distributions used for?

Enterprise Linux distributions are often used in large-scale IT environments with several hundred or thousand hosts. In this kind of environments, reproducibility (by orchestration/ automatization), reliability, compatibility and hardened concepts and versions are key aspects.

In large orchestrated IT environments, an often selected choice for a distribution as a base is CentOS since, being an Enterprise Linux distribution, its main focus aims at being a rock-stable “enterprise-class” platform prioritized over delivering the latest upstream versions of software selections. It also aims at being binary compatible to RedHat Enterprise Linux (RHEL) while being free of charge and only community supported.

Talking about CentOS …

 

CentOS logo

I will stick to CentOS here since this is the Enterprise Linux I utilize the most. But since we are talking about “Enterprise Linux” here, the following should largely apply for similar distributions, also.

At the time of this writing, CentOS 7, is the latest release of the distribution and was released in 07/2014. It will receive full updates until Q4/2020 and stay maintained (provided with Critical impact Security Advisories (RHSAs) and selected Urgent Priority Bug Fix Advisories (RHBAs) only) until 07/2024.
CentOS 6 also is still around; released in 07/2011, it’s maintenance will be continued until 11/2020.
CentOS 5 (released in 04/2007) exceeded it’s maintenance timeframe in 03/2017 and is considered unsupported.
Thus, I will only consider CentOS 7 and 6 here.
For details, please see CentOS Product Specifications and Red Hat Enterprise Linux Life Cycle.

Talking about Python …

Python logo

System Default and base repo

CentOS utilizes Python a lot for its command line tools. In fact, it’s primary package manager yum is heavily depending on Python 2 (2.7.5 in CentOS 7, 2.6.6 in CentOS 6 – provided by the package named “python” from “base” repo) and uninstalling it by force is a reliable way to render your package management useless. This version of Python also comes with some modules installed, which are hard to find in the most common locations like PyPI, including:

  • yum-metadata-parser
  • slip.dbus

In short: You do not want to mess around with this system interpreter! 💣

What about Python 3?

Python 3 is not available in either CentOS 6 or 7.

Python 3.0 was released in 12/2008.
CentOS 6 was released in 07/2011.
CentOS 7 was released in 07/2014.

Normally one would consider that to be a fair amount of time to add any release of a major technique to even an Enterprise Linux; especially with the Python 2 End of Life in sight for 2020. But – as you can see, it hasn’t been done yet. Remember what I said about the downsides of an Enterprise Linux? Here’s an example 😉
But you still have choices.

Using EPEL

The most convenient way to get Python 3 for any supported Enterprise Linux is by adding the EPEL repository to your system. This also has the benefit that its usage is quite common and so the risk to end up with a too customized system is not that huge.
Also, EPEL’s Guidelines and Policies aim to not interfere with any base package and also have quite a strict upgrade policy.
Also, the project is somewhat very close to RedHats own development, since it was born out of Fedora and Fedora is sponsored by RedHat and it is aimed to be used in their Enterprise Distribution, also.

EPEL provides Python 3.4.5 for both, CentOS 6 and 7.

If that satisfies your needs, this is quite a low hanging fruit. You add EPEL and install Python 3 from it like this:

Using IUS

IUS (Inline with Upstream Stable) is a project which is sponsored by Rackspace. It aims at providing more recent versions of some major key software packages, including Python.

It’s goals and philosophies are very close to those of EPEL in not to interfere with base packages. It’s naming convention makes sure that even if a package equivalent will ever show up in base, it will never interfere with those provided by IUS.
It considers itself a “SafeRepo” and compares itself with EPEL here; feel free to read this resource if want to learn more.

IUS provides several versions of Python:

  • 3.4.7 (package python34u)
  • 3.5.4 (package python35u)
  • 3.6.4 (package python36u)

If this satisfies your needs, this is also quite easy to achieve by issuing the following:

Installing from source

This is by far the most flexible approach while also the most cumbersome one. Also, this is not an “Enterprise Linux” specific task but can be done on any Linux system in the more or like the same way.
Please consider the fact that this is some kind of an anti-pattern if you think of what’s the goal and philosophy behind Enterprise Linux distributions.

By compiling from source, you can freely decide which version of Python you want to use. But at the same time, you sacrifice all benefits package managers have to offer, including:

  • Ease of installation
  • Package QA and reviewing workflow
  • Being supplied with security updates
  • Integration and availability to the package manager, often integrated into other orchestration tools

This approach will not be described here since it has already been done an uncountable amount of times (see here, or here, or any of the other ~973.000 results from a Google search) and since it is not really an Enterprise Linux approach.

Born in 1982, Marc Richter is an IT enthusiastic since 1994. He became addicted when he first put hands on their family’s pc and never stopped investigating and exploring new things since then.
He is married to Jennifer Richter and proud father of two wonderful children, Lotta and Linus.
His current professional focus is DevOps and Python development.

An exhaustive bio can be found at this blog post.

Found my articles useful? Maybe you would like to support my efforts and give me a tip then?